From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/3] nand: lpc32xx: add SLC NAND driver
Date: Fri, 17 Jul 2015 18:01:45 -0500 [thread overview]
Message-ID: <1437174105.2993.199.camel@freescale.com> (raw)
In-Reply-To: <4F172219764C784B84C2C1FF44E7DFB102FF1F78@003FCH1MPN2-042.003f.mgd2.msft.net>
On Fri, 2015-07-17 at 22:24 +0000, LEMIEUX, SYLVAIN wrote:
> Hi Albert,
>
> Thanks for the feedback.
>
> > From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Albert
> > ARIBAUD
> > Sent: 17-Jul-15 5:20 PM
> >
> > Hello Sylvain,
> >
> > On Fri, 17 Jul 2015 16:48:52 -0400, slemieux.tyco at gmail.com
> > <slemieux.tyco@gmail.com> wrote:
> >
> > > 1) Fixed checkpatch script output in legacy code.
> > > A single warning remaining.
> >
> > > The following warning from the legacy code is still present:
> > > lpc32xx_nand.c:195: WARNING: Use of volatile is usually wrong: see
> > > Documentation/volatile-considered-harmful.txt
> >
> > > +static u_char lpc32xx_read_byte(struct mtd_info *mtd)
> > > +{
> > > + struct nand_chip *this = mtd->priv;
> > > + unsigned long *preg = (unsigned long *)this->IO_ADDR_R;
> > > + volatile unsigned long tmp32;
> > > + tmp32 = *preg;
> > > + return (u_char)tmp32;
> > > +}
> >
> > The volatile above has no reason to exist; the warning is justified
> > here as we have accessors that guarantee that the access will not be
> > optimized away or reordered, juste like the 'volatile' above tries to
> > do (and yes, these accessors *use* 'volatile'. All the more a reason
> > not to use it again here).
> >
> > Besides, the code is quite verbose and not precise enough. Yes,
> > 'unsigned long' is 32-bit-ish, but in U-Boot, when something is 32-bit,
> > that is explicit.
> >
> > All in all, the whole function could be expressed as:
> >
> > static u_char lpc32xx_read_byte(struct mtd_info *mtd)
> > {
> > struct nand_chip *this = mtd->priv;
> >
> > return (u_char)readl(this->IO_ADDR_R);
> > }
> >
> > BTW, isn't IO_ADDR_R pointing to the data register, and isn't the data
> > register 16-bits? And if so, then why the 32-bits read?
> >
>
> The register is 16 bits; this implementation is the porting of the initial
> code.
> I will wait for feedback and see how we want to approach this
> (add DMA and HW ECC to the NAND SLC driver sent by Vladimir or
> update the driver as part of the porting effort).
If the register is 16-bit, then you should use readw(), not readl().
Why are there two different versions of this driver being submitted in
parallel?
-Scott
next prev parent reply other threads:[~2015-07-17 23:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-17 20:48 [U-Boot] [PATCH 1/3] nand: lpc32xx: add SLC NAND driver slemieux.tyco at gmail.com
2015-07-17 21:20 ` Albert ARIBAUD
2015-07-17 22:24 ` LEMIEUX, SYLVAIN
2015-07-17 23:01 ` Scott Wood [this message]
2015-07-17 23:10 ` Vladimir Zapolskiy
2015-07-17 23:46 ` LEMIEUX, SYLVAIN
2015-07-18 5:50 ` Albert ARIBAUD
2015-07-27 21:45 ` LEMIEUX, SYLVAIN
2015-07-28 0:21 ` Vladimir Zapolskiy
2015-07-28 16:28 ` LEMIEUX, SYLVAIN
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=1437174105.2993.199.camel@freescale.com \
--to=scottwood@freescale.com \
--cc=u-boot@lists.denx.de \
/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.