AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<maxim.kozlovsky@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E06883109@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Mon, 12 Nov 2007 11:06:29 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Maxim Kozlovsky" <maxim.kozlovsky@onstor.com>
Subject: Re: Please review
Message-ID: <20071112110629.0baa6ca4@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E06883109@onstor-exch02.onstor.net>
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>
	<BB375AF679D4A34E9CA8DFA650E2B04E06883109@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

OK.

On Mon, 12 Nov 2007 10:58:32 -0800 "Maxim Kozlovsky"
<maxim.kozlovsky@onstor.com> wrote:

> 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 = *ppos;
> >> >> >+#else
> >> >> >        unsigned long p = *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 += sz;
> >> >> >-        p += sz;
> >> >> >+        p = (unsigned)p + sz;
> >> >> >         read += sz;
> >> >> >         count -= 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 = *ppos;
> >> >> >+#else
> >> >> >        unsigned long p = *ppos;
> >> >> >+#endif
> >> >> >
> >> >> >-    if ((*ppos >> 28) != 0xb) {
> >> >> >+    if (((*ppos >> 28) & 0xf) != 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
> >>
