X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C8255E.054CB8A0@onstor-exch02.onstor.net>; Mon, 12 Nov 2007 10:58:32 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: Please review
Date: Mon, 12 Nov 2007 10:58:32 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E06883109@onstor-exch02.onstor.net>
In-Reply-To: <20071112105510.2cd32062@ripper.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Please review
Thread-Index: AcglXYzrrfZ7qv1HSI2Zg1xvOZkiuQAAEisg
References: <BB375AF679D4A34E9CA8DFA650E2B04E06882B8A@onstor-exch02.onstor.net><20071109163628.1efdb0bd@ripper.onstor.net><BB375AF679D4A34E9CA8DFA650E2B04E06882C85@onstor-exch02.onstor.net><20071109163913.1dfd6e2d@ripper.onstor.net><BB375AF679D4A34E9CA8DFA650E2B04E06882C8C@onstor-exch02.onstor.net><20071109170631.76a42772@ripper.onstor.net><BB375AF679D4A34E9CA8DFA650E2B04E06882CCA@onstor-exch02.onstor.net><20071109180244.6aaa36cf@ripper.onstor.net><BB375AF679D4A34E9CA8DFA650E2B04E068830F1@onstor-exch02.onstor.net> <20071112105510.2cd32062@ripper.onstor.net>
From: "Maxim Kozlovsky" <maxim.kozlovsky@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>

It is called from more than one place, the other places where broken,
now everything is fixed.

>-----Original Message-----
>From: Andy Sharp
>Sent: Monday, November 12, 2007 10:55 AM
>To: Maxim Kozlovsky
>Subject: Re: Please review
>
>Well, if that one routine is only called from one place, then remove it
>as a function call.  Otherwise, yes.  Stupid hardware
>change-the-address-every-other-day knuckleheads.
>
>On Mon, 12 Nov 2007 10:54:00 -0800 "Maxim Kozlovsky"
><maxim.kozlovsky@onstor.com> wrote:
>
>> So is it ok to check in?
>>
>> >-----Original Message-----
>> >From: Andy Sharp
>> >Sent: Friday, November 09, 2007 6:03 PM
>> >To: Maxim Kozlovsky
>> >Subject: Re: Please review
>> >
>> >On Fri, 9 Nov 2007 17:10:05 -0800 "Maxim Kozlovsky"
>> ><maxim.kozlovsky@onstor.com> wrote:
>> >
>> >> It is ugly and it will not work for bmfpga accesses.
>> >
>> >It's the most beautiful code ever, especially compared to yours.
>> >It's so beautiful, it doesn't even matter if it doesn't work.
>> >That's just how beautiful it is.
>> >
>> >Nevertheless, I have included a review below.  A /proc driver would
>> >be so much better....
>> >
>> >> >-----Original Message-----
>> >> >From: Andy Sharp
>> >> >Sent: Friday, November 09, 2007 5:07 PM
>> >> >To: Maxim Kozlovsky
>> >> >Cc: Tim Gardner
>> >> >Subject: Re: Please review
>> >> >
>> >> >You didn't expect me to pay attention, did you?
>> >> >
>> >> >This should be all that is needed to make the current user code
>> >> >work unmodified:
>> >> >
>> >> >diff --git a/drivers/char/mem.c b/drivers/char/mem.c
>> >> >index 1d58db4..d160b37 100644
>> >> >--- a/drivers/char/mem.c
>> >> >+++ b/drivers/char/mem.c
>> >> >@@ -555,7 +555,14 @@ static ssize_t write_kmem(struct file *
file,
>> >> const
>> >> >char __
>> >> > static ssize_t read_port(struct file * file, char __user * buf,
>> >> >                         size_t count, loff_t *ppos)
>> >> > {
>> >> >+       /*
>> >> >+        * on MIPS64, virtual addresses in kseg0/1 must be sign
>> >> extended
>> >> >+        */
>> >> >+#ifdef CONFIG_64BIT
>> >> >+       long long p =3D *ppos;
>> >> >+#else
>> >> >        unsigned long p =3D *ppos;
>> >> >+#endif
>> >> >        ssize_t read, sz;
>> >> >        char * kbuf; /* k-addr because vread() takes vmlist_lock
>> >> > rwlock
>> >> */
>> >> >
>> >> >@@ -595,7 +602,7 @@ static ssize_t read_port(struct file * file,
>> char
>> >> >__user * b
>> >> >         if (copy_to_user(buf, kbuf, sz))
>> >> >             return -EFAULT;
>> >> >         buf +=3D sz;
>> >> >-        p +=3D sz;
>> >> >+        p =3D (unsigned)p + sz;
>> >> >         read +=3D sz;
>> >> >         count -=3D sz;
>> >> >     }
>> >> >@@ -607,9 +614,13 @@ static ssize_t read_port(struct file * file,
>> >> >char __user *
>> >> > static ssize_t write_port(struct file * file, const char __user
*
>> >> > buf, size_t count, loff_t *ppos)
>> >> > {
>> >> >+#ifdef CONFIG_64BIT
>> >> >+       long long p =3D *ppos;
>> >> >+#else
>> >> >        unsigned long p =3D *ppos;
>> >> >+#endif
>> >> >
>> >> >-    if ((*ppos >> 28) !=3D 0xb) {
>> >> >+    if (((*ppos >> 28) & 0xf) !=3D 0xb) {
>> >> >         return -EINVAL;
>> >> >     }
>> >> >
>> >> >
>> >> >On Fri, 9 Nov 2007 16:40:05 -0800 "Maxim Kozlovsky"
>> >> ><maxim.kozlovsky@onstor.com> wrote:
>> >> >
>> >> >> This does not work. Where have you been while I explained about
>> >> >> negative offsets?
>> >> >>
>> >> >> >-----Original Message-----
>> >> >> >From: Andy Sharp
>> >> >> >Sent: Friday, November 09, 2007 4:39 PM
>> >> >> >To: Maxim Kozlovsky
>> >> >> >Subject: Re: Please review
>> >> >> >
>> >> >> >Checked in many moons ago, look for ifdef CONFIG_MIPS for
>> >> read_port()
>> >> >> >and write_port().
>> >> >> >
>> >> >> >On Fri, 9 Nov 2007 16:38:13 -0800 "Maxim Kozlovsky"
>> >> >> ><maxim.kozlovsky@onstor.com> wrote:
>> >> >> >
>> >> >> >> Where are the modifications? I don't see anything checked
in.
>> >> >> >>
>> >> >> >> >-----Original Message-----
>> >> >> >> >From: Andy Sharp
>> >> >> >> >Sent: Friday, November 09, 2007 4:36 PM
>> >> >> >> >To: Maxim Kozlovsky
>> >> >> >> >Subject: Re: Please review
>> >> >> >> >
>> >> >> >> >None of this should be necessary.  Especially the bsd
>> >> >> >> >related changes. Linux uses /dev/port which has already
>> >> >> >> >been modified and should work fine without any further
mods.
>> >> >> >> >
>> >> >> >> >On Fri, 9 Nov 2007 14:42:39 -0800 "Maxim Kozlovsky"
>> >> >> >> ><maxim.kozlovsky@onstor.com> wrote:
>> >> >> >> >
>> >> >> >> >> Change 26287 by maximk@maximk-13 on 2007/11/09 14:34:58
>> >> >> >> >> *pending*
>> >> >> >> >>
>> >> >> >> >>         Add a device allowing the user processes to whack
>> >> >> >> >> at physical memory
>> >> >> >> >>            whenever they want.
>> >> >> >> >>
>> >> >> >> >>            Change the bmfpga and galileo / sibyte
register
>> >> >> accesses
>> >> >> >> >> from chassisd to use plain physical addresses instead of
>> >> >> >> >> KSEG1 addresses.
>> >> >> >> >>
>> >> >> >> >>            Set the offset to access the physical memory
to
>> >> >> >> >> 0xa0000000 for BSD
>> >> >> >> >>            resulting in old behavior where the KSEG1 is
>> >> accesses
>> >> >> >> >> and to 0 for
>> >> >> >> >>            Linux, which uses the new device on bobcat and
>> >> >> >> >> cougar.
>> >> >> >> >>
>> >> >> >> >>            Reviewed by andys.
>> >> >> >> >>
>> >> >> >> >> Affected files ...
>> >> >> >> >>
>> >> >> >> >> ...
>> >> //depot/dev/linux/kernel/linux-mips-2.6/drivers/char/mem.c#2
>> >> >> >> >> edit ...
//depot/dev/nfx-tree/code/sm-chassis/chassis-ui.c#6
>> >> >> >> >> edit ...
>> //depot/dev/nfx-tree/code/sm-chassis/chassisd-bc.c#5
>> >> >> >> >> edit ...
//depot/dev/nfx-tree/code/sm-chassis/cm-api-bc.h#3
>> >> edit
>> >> >> >> >> ... //depot/dev/nfx-tree/code/sm-chassis/linux.h#1 edit
>> >> >> >> >> ... //depot/dev/nfx-tree/code/sm-chassis/openbsd.h#1 edit
>> >> >> >> >> ... //depot/dev/nfx-tree/code/ssc-genlib/cm-util-bc.c#3
>> >> >> >> >> edit ... //depot/dev/nfx-tree/code/ssc-genlib/linux.h#1
>> >> >> >> >> edit ... //depot/dev/nfx-tree/code/ssc-genlib/openbsd.h#1
>> >> >> >> >> edit
>> >> >> >> >>
>> >
>> >Is this tested on something-linux?  I'm wondering if udev is
creating
>> >the device node for us like a good little boy, or if we have to add
>> >it to the rootfs/udev stuff.
>> >
>> >linux/kernel/linux-mips-2.6/drivers/char/mem.c
>> >
>> >     line 995, don't say sibyte
>> >
>> >nfx-tree/code/sm-chassis/chassis-ui.c
>> >
>> >     looks good
>> >
>> >nfx-tree/code/sm-chassis/chassisd-bc.c
>> >
>> >     line 1133 you're not unlocking the i2c lock anymore...
>> >
>> >nfx-tree/code/sm-chassis/cm-api-bc.h
>> >
>> >     looks good
>> >
>> >nfx-tree/code/sm-chassis/linux.h
>> >
>> >     looks good
>> >
>> >nfx-tree/code/sm-chassis/openbsd.h
>> >
>> >     looks good
>> >
>> >nfx-tree/code/ssc-genlib/cm-util-bc.c
>> >
>> >     line 88, this looks broken to me.  we're poking at semaphore
>> >     internal values??  if you're changing the semantics of this
>> >     routine, are there any other callers that need to be changed?
>> >
>> >nfx-tree/code/ssc-genlib/linux.h
>> >
>> >     looks good
>> >
>> >nfx-tree/code/ssc-genlib/openbsd.h
>> >
>> >     looks good
>>
