All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.