[U-Boot] [PATCH] nand: reinstate lazy bad block scanning

[Masahiro Yamada]

Hi Scott,

On Tue, 4 Nov 2014 23:49:36 -0600
Scott Wood <scottwood at freescale.com> wrote:

> On Wed, 2014-11-05 at 12:40 +0900, Masahiro Yamada wrote:
> > Hi Scott, Rostislav,
> > 
> > On Mon, 3 Nov 2014 15:42:29 -0600
> > Scott Wood <scottwood at freescale.com> wrote:
> > 
> > > On Wed, 2014-10-22 at 13:40 +0200, Rostislav Lisovy wrote:
> > > > Commit ff94bc40af3481d47546595ba73c136de6af6929
> > > > ("mtd, ubi, ubifs: resync with Linux-3.14")
> > > > accidentally reverted part of the commit
> > > > 13f0fd94e3cae6f8a0d9fba5d367e311edc8ebde
> > > > ("NAND: Scan bad blocks lazily.").
> > > > 
> > > > Reinstate the change as by commit
> > > > fb49454b1b6c7c6e238ac3c0b1e302e73eb1a1ea
> > > > ("nand: reinstate lazy bad block scanning")
> > > > 
> > > > Signed-off-by: Rostislav Lisovy <lisovy at merica.cz>
> > > > ---
> > > >  drivers/mtd/nand/nand_base.c | 10 +++++++---
> > > >  1 file changed, 7 insertions(+), 3 deletions(-)
> > > 
> > > Thanks for catching this.  
> > > 
> > > Heiko, this is the sort of thing I was concerned about with the "resync
> > > from scratch" approach.
> > > 
> > 
> > I do not believe resync is a bad idea,
> > of course we should be very careful not to break existing features.
> 
> I'm not saying don't sync -- I'm saying do it by generating a diff based
> on the last sync (which is what all the previous NAND updates did),
> rather than throwing out the U-Boot code and replacing it with Linux
> files, and then fixing any problems encountered (which may be a subset
> of the problems existing).
> 
> > I recommend to surround this code with "#ifdef __UBOOT__  ... #endif"
> > as we have done for the other parts.
> 
> I recommend not making such a mess, for reasons I've described
> previously.
> 
> > BTW, we attempt to probe NAND devices during the boot sequence
> > just for displaying the device size, right?
> > 
> > NAND:  **** MiB
> > 
> > 
> > If so, can we postpone the whole of nand_scan
> > until we use it?  I am not sure about this, though.
> 
> Possibly.  IIRC someone once posted a patch trying to do this, but it
> was missing an initialization check on some paths where NAND could be
> accessed, and the patchset never got respun.
> 

In Simon's driver model, devices are probed when they are actually used.
Perhaps we can change this when we introduce driver model to NAND.



Best Regards
Masahiro Yamada