AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20071112105500.5b9937e7@ripper.onstor.net>
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	BB375AF679D4A34E9CA8DFA650E2B04E068830F1@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Mon, 12 Nov 2007 10:55:10 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Maxim Kozlovsky" <maxim.kozlovsky@onstor.com>
Subject: Re: Please review
Message-ID: <20071112105510.2cd32062@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E068830F1@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>
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

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
> 
