X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C8255D.633086F5@onstor-exch02.onstor.net>; Mon, 12 Nov 2007 10:54:00 -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:54:00 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E068830F1@onstor-exch02.onstor.net>
In-Reply-To: <20071109180244.6aaa36cf@ripper.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Please review
Thread-Index: AcgjPciDewvUgjoZRbW+rS6Cfe6IDQCH5M+g
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>
From: "Maxim Kozlovsky" <maxim.kozlovsky@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>

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

