From: "Masayuki Ohtake" <masa-korg@dsn.okisemi.com>
To: "Andy Isaacson" <adi@hexapodia.org>
Cc: "Arnd Bergmann" <arnd@arndb.de>,
"Wang, Yong Y" <yong.y.wang@intel.com>,
"Wang Qi" <qi.wang@intel.com>, "Intel OTC" <joel.clark@intel.com>,
"Andrew" <andrew.chih.howe.khor@intel.com>,
"Alan Cox" <alan@lxorguk.ukuu.org.uk>,
"LKML" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Topcliff PHUB: Generate PacketHub driver
Date: Thu, 1 Jul 2010 13:08:59 +0900 [thread overview]
Message-ID: <000401cb18d3$22f6d940$66f8800a@maildom.okisemi.com> (raw)
In-Reply-To: 20100630182829.GJ29166@hexapodia.org
Hi Andy,
> 1. When writing comments, do not write comments that duplicate the code.
> Instead of writing
Our Phub patch I have resubmitted yesterday have been already modified above.
> 2. your register names are very long. Since the #define names are
> private to this driver, there's no need to make them extremely
> descriptive. Instead of naming your registers
> PCH_PHUB_PHUB_ID_REG, you should change the names to be shorter, like
> PHUB_ID_REG or PCH_ID_REG. This will make your source code much more
> readable by reducing linewrapping.
This was our mistake.
I have modified PCH_PHUB_PHUB_ID_REG to PCH_PHUB_ID_REG.
Our Phub patch I have resubmitted yesterday have been already modified above.
> It sounds like PHUB is a system-level device which provides access to a
> SROM which contains GbE configuration data. If that is correct, then I
> have two comments:
Yes, SROM has GbE configuration data (GbE mac address) .
>
> 1. There are many other systems with similar configurations -- MIPS
> SiByte, Alpha SRM, SPARC OpenFirmware, and some ARM systems, just to
> name a few. None of them expose the SROM as a custom /dev node AFAIK.
> Is there a shared infrastructure that you can implement?
Sorry, I can't understand your intension.
Please give me more detail.
>
> 2. How does your GbE driver get the MAC address from the SPROM? If
> there is an in-kernel user of the PHUB interface, it might be much
> easier to understand the design.
PHUB HW transfers MAC address(in SROM) data to GbE register to set MAC address when boot processing.
Thanks, Ohtake
----- Original Message -----
From: "Andy Isaacson" <adi@hexapodia.org>
To: "Masayuki Ohtake" <masa-korg@dsn.okisemi.com>
Cc: "Arnd Bergmann" <arnd@arndb.de>; "Wang, Yong Y" <yong.y.wang@intel.com>; "Wang Qi" <qi.wang@intel.com>; "Intel OTC"
<joel.clark@intel.com>; "Andrew" <andrew.chih.howe.khor@intel.com>; "Alan Cox" <alan@lxorguk.ukuu.org.uk>; "LKML"
<linux-kernel@vger.kernel.org>
Sent: Thursday, July 01, 2010 3:28 AM
Subject: Re: [PATCH] Topcliff PHUB: Generate PacketHub driver
> On Wed, Jun 30, 2010 at 02:58:25PM +0900, Masayuki Ohtake wrote:
> > > > + unsigned int i;
> > > > + void __iomem *p = pch_phub_reg.pch_phub_base_address;
> > > > +
> > > > + dev_dbg(&pdev->dev, "pch_phub_restore_reg_conf ENTRY\n");
> > > > + /* to store contents of PHUB_ID register */
> > > > + iowrite32(pch_phub_reg.phub_id_reg, p + PCH_PHUB_PHUB_ID_REG);
> > >
> > > Don't include comments that just duplicate the code. Also, rename your
> > > constants from PCH_PHUB_PHUB_ to, I dunno, PHUB_ or something.
> >
> > Sorry, I can't understand your intention.
> > Please give us more information.
>
> My mistake, I merged two comments into one paragraph, let me clarify.
>
> 1. When writing comments, do not write comments that duplicate the code.
> Instead of writing
> /* store PHUB_ID */
> iowrite32(..._PHUB_ID_REG);
> /* store PHUB_FOO */
> iowrite32(..._PHUB_FOO_REG);
> you should delete the line-by-line comments and just write
> iowrite32(..._PHUB_ID_REG);
> iowrite32(..._PHUB_FOO_REG);
>
> 2. your register names are very long. Since the #define names are
> private to this driver, there's no need to make them extremely
> descriptive. Instead of naming your registers
> PCH_PHUB_PHUB_ID_REG, you should change the names to be shorter, like
> PHUB_ID_REG or PCH_ID_REG. This will make your source code much more
> readable by reducing linewrapping.
>
> > > I seriously doubt that your device is special enough to warrant a custom
> > > /dev node with proprietary semantics. If this is just part of an
> > > Ethernet driver, please implement it in drivers/net/; if this is a
> > > generic PROM accessor, there must be some semi-standardized EPROM access
> > > interface but I don't know what it is offhand.
> >
> > Since SROM is not in GbE HW but Phub HW, Phub is not part of Ethernet driver.
> > Packet hub is not generic driver but special device.
>
> It sounds like PHUB is a system-level device which provides access to a
> SROM which contains GbE configuration data. If that is correct, then I
> have two comments:
>
> 1. There are many other systems with similar configurations -- MIPS
> SiByte, Alpha SRM, SPARC OpenFirmware, and some ARM systems, just to
> name a few. None of them expose the SROM as a custom /dev node AFAIK.
> Is there a shared infrastructure that you can implement?
>
> 2. How does your GbE driver get the MAC address from the SPROM? If
> there is an in-kernel user of the PHUB interface, it might be much
> easier to understand the design.
>
> Thanks for responding to my review so quickly!
> -andy
>
next prev parent reply other threads:[~2010-07-01 4:09 UTC|newest]
Thread overview: 72+ 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 [this message]
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
2010-07-15 7:25 ` Masayuki Ohtak
2010-07-15 7:42 ` [PATCH] I2C " Masayuki Ohtak
2010-07-15 19:35 ` Arnd Bergmann
2010-07-20 0:05 ` Masayuki Ohtake
2010-07-20 4:55 ` Masayuki Ohtake
2010-07-20 9:27 ` Arnd Bergmann
2010-07-20 12:38 ` Masayuki Ohtake
2010-07-20 8:19 ` Masayuki Ohtake
2010-07-20 9:29 ` Arnd Bergmann
2010-07-20 12:40 ` Masayuki Ohtake
2010-07-21 6:46 ` Masayuki Ohtak
-- strict thread matches above, loose matches on Subject: below --
2010-06-22 2:14 [PATCH] Topcliff PHUB: Generate PacketHub driver Masayuki Ohtake
2010-06-15 6:58 Masayuki Ohtake
2010-06-15 10:37 ` Arnd Bergmann
2010-06-15 12:14 ` Masayuki Ohtake
2010-06-16 8:58 ` Masayuki Ohtake
2010-06-16 10:50 ` Arnd Bergmann
2010-06-17 0:17 ` Masayuki Ohtake
2010-06-08 5:00 Masayuki Ohtak
2010-06-08 5:46 ` Masayuki Ohtake
2010-06-08 8:01 ` Alan Cox
2010-06-08 7:20 ` Yong Wang
2010-06-08 8:09 ` Masayuki Ohtake
2010-06-08 8:04 ` Alan Cox
2010-06-07 12:39 Masayuki Ohtak
2010-06-07 15:05 ` Alan Cox
2010-06-08 0:19 ` Masayuki Ohtake
2010-06-14 12:09 ` Masayuki Ohtak
2010-06-14 12:50 ` Arnd Bergmann
2010-06-14 23:56 ` Masayuki Ohtake
2010-06-15 6:25 ` Masayuki Ohtake
2010-06-15 10:42 ` Arnd Bergmann
2010-06-15 12:12 ` Masayuki Ohtake
2010-06-17 2:43 ` Masayuki Ohtak
2010-06-17 11:59 ` Arnd Bergmann
2010-06-17 23:49 ` Masayuki Ohtake
2010-06-18 8:08 ` Wang, Yong Y
2010-06-18 11:39 ` Masayuki Ohtake
2010-06-04 10:16 Masayuki Ohtake
2010-06-04 12:00 ` Alan Cox
2010-06-07 7:53 ` Masayuki Ohtake
2010-06-07 13:37 ` Arnd Bergmann
2010-06-08 0:15 ` Masayuki Ohtake
2010-06-08 8:48 ` Masayuki Ohtake
2010-06-08 9:29 ` Arnd Bergmann
2010-06-09 0:14 ` Wang, Qi
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='000401cb18d3$22f6d940$66f8800a@maildom.okisemi.com' \
--to=masa-korg@dsn.okisemi.com \
--cc=adi@hexapodia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox