[U-Boot] [PATCH 1/5] nand: Use common read function instead of verify_buf()

[Scott Wood <scottwood@freescale.com>]

On Tue, 2015-01-27 at 17:47 -0600, Peter Tyser wrote:
> Hi Scott,
> 
> 
> > > I waffled about removing it, but leaned towards leaving it in because:
> > > - I didn't want to change the existing U-Boot behavior for other
> > > users.  A google of 'u-boot "nand write"' shows a lot of examples that
> > > don't include verification of writes, and they should if we remove
> > > auto-verification.
> > 
> > How many configs actually enable this option?  I don't see many beyond
> > the FSL PPC boards (which are so full of copy-and-paste that it probably
> > wasn't deliberate).
> 
> Yeah, the majority are FSL 83xx and 85xx, with 2 or so random ARM boards.
> 
> > > - The reason it was removed in Linux was "Both UBI and JFFS2 are able
> > > to read verify what they wrote already.  There are also MTD tests
> > > which do this verification."  I thought U-Boot was more likely than
> > > Linux to use raw NAND writes without a filesystem, so leaving it in U-
> > > Boot made sense since the UBI/JFFS2 logic didn't apply as much here.
> > 
> > Right, though raw writes ought to be limited to blocks that aren't
> > written often enough to fail.
> > 
> > > - I didn't think a lot of people would know they have to explicitly
> > > verify NAND contents after a write, since they'd assume it was like
> > > other memories that aren't as lossy.
> > > 
> > > - The penalty of slightly different code from Linux and a small
> > > performance hit was worth the gain of auto-verification to me.  I
> > > viewed consolidating it into one small chunk of code as a happy medium.
> > 
> > The davinci patches show that there can still be driver dependencies
> > depending on what the driver overrides.  I'm not hugely opposed, but it
> > seems like it would be better to do it at a higher level (e.g. in
> > nand_util.c with a flag to enable, and either make support mandatory, or
> > if you try to use that command variant without support it fails rather
> > than silently not verifying).
> 
> That seems like a good idea.  How about:
> - Remove all CONFIG_MTD_NAND_VERIFY_WRITE references
> 
> - Add a new flag WITH_WR_VERIFY and have nand_write_skip_bad() in 
> nand_util.c verify writes only when it is set.
> 
> - Update the calls to nand_write_skip_bad() in cmd_nand.c to include
> the new WITH_WR_VERIFY flag.  I'd vote to enable it for all boards,
> but let me know if you disagree.
> 
> That would make all "nand write" commands verify writes, with the
> exception of "nand write.raw".  Any opinion on if this should also
> be verified?  I only use it for development/testing, so don't have
> a strong opinion.

"raw" refers to the absence of ECC, and I'd rather not overload it to
mean "don't verify".  Should it also be possible to request non-raw
non-verified accesses?  Or should we always verify and wait until
someone complains about performance?

What about DFU and other non-cmd_nand NAND accesses?

-Scott