From: "Masayuki Ohtake" <masa-korg@dsn.okisemi.com>
To: "Andrew Morton" <akpm@linux-foundation.org>
Cc: "LKML" <linux-kernel@vger.kernel.org>,
"Alan Cox" <alan@lxorguk.ukuu.org.uk>,
<andrew.chih.howe.khor@intel.com>,
"Intel OTC" <joel.clark@intel.com>,
"Wang, Qi" <qi.wang@intel.com>,
"Wang, Yong Y" <yong.y.wang@intel.com>,
"Arnd Bergmann" <arnd@arndb.de>
Subject: Re: [PATCH] Packet hub driver of Topcliff PCH
Date: Mon, 12 Jul 2010 10:25:03 +0900 [thread overview]
Message-ID: <09ac01cb2161$158c4650$66f8800a@maildom.okisemi.com> (raw)
In-Reply-To: 20100709130028.26174aa1.akpm@linux-foundation.org
Hi Andrew Morton
> The driver creates a character device /dev/pch_phub. That device file
> supports the following operations:
>
> read(): <document the read operation - seems to read a serial ROM?>
> write():<document the write operation - seems to write a serial ROM?>
> ioctl():<document the ioctl operation - seems to read/write a MAC address?>
We will add the above.
> I suspect this function will do strange things if passed an initial
> *ppos which is outside the range of the ROM. It looks like it will write
> a single byte into the ROM then will bale out.
>
>
> > + if (ret_value2) {
> > + err = ret_value2;
> > + goto return_err;
> > + }
> > +
> > + if (PCH_PHUB_OROM_SIZE < pos + addr_offset) {
>
> Is this off-by-one?
I understand OROM upper size check is not enough.
If the my understanding true, We will modify like below.
Can you accept the following our modification ?
+static ssize_t pch_phub_write(struct file *file, const char __user *buf,
+ size_t size, loff_t *ppos)
+{
+ unsigned int data;
+ int ret_value1;
+ int ret_value2;
+ int err;
+ unsigned int addr_offset;
+ loff_t pos = *ppos;
+ int ret;
+
+ ret = mutex_lock_interruptible(&pch_phub_mutex);
+ if (ret) {
+ err = -ERESTARTSYS;
+ goto return_err_nomutex;
+ }
+
+ for (addr_offset = 0; addr_offset < size; addr_offset++) {
+ if (PCH_PHUB_OROM_SIZE < pos + addr_offset) {
+ *ppos += addr_offset;
+ goto return_ok;
+ }
+ ret_value1 = get_user(data, &buf[addr_offset]);
+ if (ret_value1) {
+ err = -EFAULT;
+ goto return_err;
+ }
+
+ ret_value2 = pch_phub_write_serial_rom(0x80 + addr_offset + pos,
+ data);
+ if (ret_value2) {
+ err = ret_value2;
+ goto return_err;
+ }
+
Thanks, Ohtake
----- Original Message -----
From: "Andrew Morton" <akpm@linux-foundation.org>
To: "Masayuki Ohtak" <masa-korg@dsn.okisemi.com>
Cc: "Arnd Bergmann" <arnd@arndb.de>; "Wang, Yong Y" <yong.y.wang@intel.com>; <qi.wang@intel.com>;
<joel.clark@intel.com>; <andrew.chih.howe.khor@intel.com>; "Alan Cox" <alan@lxorguk.ukuu.org.uk>; "LKML"
<linux-kernel@vger.kernel.org>
Sent: Saturday, July 10, 2010 5:00 AM
Subject: Re: [PATCH] Packet hub driver of Topcliff PCH
> On Tue, 06 Jul 2010 15:20:52 +0900
> Masayuki Ohtak <masa-korg@dsn.okisemi.com> wrote:
>
> > Hi Arnd
> >
> > I have modified for your comments.
> > Please confirm below.
> >
> > Thanks, Ohtake.
> >
> > ---
> > Packet hub driver of Topcliff PCH
> >
> > Topcliff PCH is the platform controller hub that is going to be used in
> > Intel's upcoming general embedded platform. All IO peripherals in
> > Topcliff PCH are actually devices sitting on AMBA bus. Packet hub is
> > a special converter device in Topcliff PCH that translate AMBA transactions
> > to PCI Express transactions and vice versa. Thus packet hub helps present
> > all IO peripherals in Topcliff PCH as PCIE devices to IA system.
> > Topcliff PCH has MAC address and Option ROM data.
> > These data are in SROM which is connected to PCIE bus.
> > Packet hub driver of Topcliff PCH can access MAC address and Option ROM data in
> > SROM.
>
> That didn't describe the most important part of the driver: the
> userspace interface. We should add here something along the lines of
>
> The driver creates a character device /dev/pch_phub. That device file
> supports the following operations:
>
> read(): <document the read operation - seems to read a serial ROM?>
> write():<document the write operation - seems to write a serial ROM?>
> ioctl():<document the ioctl operation - seems to read/write a MAC address?>
>
> >
> > ...
> >
> > +static ssize_t pch_phub_write(struct file *file, const char __user *buf,
> > + size_t size, loff_t *ppos)
> > +{
> > + unsigned int data;
> > + int ret_value1;
> > + int ret_value2;
> > + int err;
> > + unsigned int addr_offset;
> > + loff_t pos = *ppos;
> > + int ret;
> > +
> > + ret = mutex_lock_interruptible(&pch_phub_mutex);
> > + if (ret) {
> > + err = -ERESTARTSYS;
> > + goto return_err_nomutex;
> > + }
> > +
> > + for (addr_offset = 0; addr_offset < size; addr_offset++) {
> > + ret_value1 = get_user(data, &buf[addr_offset]);
> > + if (ret_value1) {
> > + err = -EFAULT;
> > + goto return_err;
> > + }
> > +
> > + ret_value2 = pch_phub_write_serial_rom(0x80 + addr_offset + pos,
> > + data);
>
> I suspect this function will do strange things if passed an initial
> *ppos which is outside the range of the ROM. It looks like it will write
> a single byte into the ROM then will bale out.
>
>
> > + if (ret_value2) {
> > + err = ret_value2;
> > + goto return_err;
> > + }
> > +
> > + if (PCH_PHUB_OROM_SIZE < pos + addr_offset) {
>
> Is this off-by-one?
>
> > + *ppos += addr_offset;
> > + goto return_ok;
> > + }
> > +
> > + }
> > +
> > + *ppos += addr_offset;
> > +
> > +return_ok:
> > + mutex_unlock(&pch_phub_mutex);
> > + return addr_offset;
> > +
> > +return_err:
> > + mutex_unlock(&pch_phub_mutex);
> > +return_err_nomutex:
> > + return err;
> > +}
> >
> > ...
> >
>
next prev parent reply other threads:[~2010-07-12 1:25 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-22 5:33 [PATCH] Topcliff PHUB: Generate PacketHub driver Masayuki Ohtak
2010-06-22 10:33 ` Masayuki Ohtak
2010-06-22 22:12 ` Andrew Morton
2010-06-23 0:31 ` Masayuki Ohtake
2010-06-22 11:30 ` Arnd Bergmann
2010-06-22 13:52 ` Yong Wang
2010-06-29 23:31 ` Andy Isaacson
2010-06-30 5:58 ` Masayuki Ohtake
2010-06-30 18:28 ` Andy Isaacson
2010-07-01 4:08 ` Masayuki Ohtake
2010-06-30 7:51 ` [PATCH] Packet hub driver of Topcliff PCH Masayuki Ohtak
2010-06-30 18:05 ` Randy Dunlap
2010-07-01 2:52 ` Masayuki Ohtake
2010-07-01 5:14 ` Masayuki Ohtak
2010-07-01 6:58 ` Andy Isaacson
2010-07-01 10:13 ` Masayuki Ohtake
2010-07-01 10:38 ` Masayuki Ohtak
2010-07-01 15:44 ` Randy Dunlap
2010-07-05 7:20 ` Masayuki Ohtak
2010-07-05 15:04 ` Arnd Bergmann
2010-07-06 15:58 ` Randy Dunlap
2010-07-06 6:20 ` Masayuki Ohtak
2010-07-06 6:30 ` Arnd Bergmann
2010-07-07 1:19 ` Yong Wang
2010-07-09 20:00 ` Andrew Morton
2010-07-12 1:25 ` Masayuki Ohtake [this message]
2010-07-15 7:25 ` Masayuki Ohtak
2010-07-15 7:42 ` [PATCH] I2C " Masayuki Ohtak
[not found] ` <4C3EBBEC.9020304-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
2010-07-15 19:35 ` Arnd Bergmann
2010-07-15 19:35 ` Arnd Bergmann
2010-07-20 0:05 ` Masayuki Ohtake
2010-07-20 0:05 ` Masayuki Ohtake
2010-07-20 4:55 ` Masayuki Ohtake
2010-07-20 4:55 ` Masayuki Ohtake
[not found] ` <000401cb27c7$ce732960$66f8800a-a06+6cuVnkTSQfdrb5gaxUEOCMrvLtNR@public.gmane.org>
2010-07-20 9:27 ` Arnd Bergmann
2010-07-20 9:27 ` Arnd Bergmann
2010-07-20 12:38 ` Masayuki Ohtake
2010-07-20 12:38 ` Masayuki Ohtake
2010-07-20 8:19 ` Masayuki Ohtake
2010-07-20 8:19 ` Masayuki Ohtake
[not found] ` <000601cb27e4$3768c170$66f8800a-a06+6cuVnkTSQfdrb5gaxUEOCMrvLtNR@public.gmane.org>
2010-07-20 9:29 ` Arnd Bergmann
2010-07-20 9:29 ` Arnd Bergmann
2010-07-20 12:40 ` Masayuki Ohtake
2010-07-20 12:40 ` Masayuki Ohtake
[not found] ` <4C204B0D.2030201-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
2010-07-21 6:46 ` Masayuki Ohtak
2010-07-21 6:46 ` Masayuki Ohtak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='09ac01cb2161$158c4650$66f8800a@maildom.okisemi.com' \
--to=masa-korg@dsn.okisemi.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andrew.chih.howe.khor@intel.com \
--cc=arnd@arndb.de \
--cc=joel.clark@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=qi.wang@intel.com \
--cc=yong.y.wang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.