Re: [RFC] nand_btt : use nand chip->block_bad

[Scott Wood <scottwood@freescale.com>]

On 09/17/2012 08:06:54 PM, Brian Norris wrote:
> Hi Shmulik, Matthieu, and others,
> 
> On Mon, Aug 6, 2012 at 3:21 PM, Brian Norris
> <computersforpeace@gmail.com> wrote:
> > On Wed, Jul 25, 2012 at 4:02 AM, Shmulik Ladkani
> >> I guess utilizing badblockbits may provide good coverage to that
> >> condition.
> >
> > Yes, I agree that badblockbits is a good solution. I'm still not  
> sure
> > that any of the above arguments really suggest that we *can't* apply
> > ECC, but for any important case, badblockbits would be more robust.  
> I
> > think I will look into fleshing out Matthieu's RFC at some point,
> > unless he's already working on it.
> 
> I've done a little work at trying to flesh out this RFC, as I'm
> thinking that we should more cleanly separate NAND BBT code and NAND
> BBM code - i.e., bad block *table* vs. bad block *marker*. Markers
> should be handled in a standard way in nand_base.c
> (nand_default_block_markbad and nand_block_bad) and then nand_bbt.c
> can be left the generic, focused job of handling the table. Now, that
> all sounds nice, but I've run across at least one difficulty... This
> approach should lead to the removal of nand_chip.badblock_pattern
> entirely, as we would only be supporting the nand_base.c badblock
> marker pattern, using nand_chip.badblockpos and a few
> nand_chip.bbt_options flags. This leads me to analyzing all the
> strange forms of badblock_pattern seen in various drivers. I'm not
> sure all of them are even well thought out...
> 
> The following files use badblock_pattern to varying degrees. Some are
> just duplicating some nand_base stuff, where we can replace the
> badblock_pattern with something simple like "chip->badblockpos = 0" or
> setting a few "chip->bbt_options |= NAND_BBT_SCAN*" options. But it's
> not all so simple:
> 
> arch/arm/mach-pxa/corgi.c
> arch/arm/mach-pxa/eseries.c
> arch/arm/mach-pxa/poodle.c
> arch/arm/mach-pxa/spitz.c
> arch/arm/mach-pxa/tosa.c
> drivers/mtd/nand/bcm_umi_nand.c
> drivers/mtd/nand/docg4.c
> drivers/mtd/nand/fsl_elbc_nand.c
> drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> drivers/mtd/nand/nand_base.c
> drivers/mtd/nand/omap2.c
> drivers/mtd/nand/sh_flctl.c
> drivers/mtd/nand/sharpsl.c
> drivers/mtd/nand/tmio_nand.c
> drivers/mtd/onenand/onenand_bbt.c
> include/linux/mfd/tmio.h
> include/linux/mtd/sharpsl.h
> 
> Any thoughts on how to tackle this? Or is it even worth doing
> properly? Is there a policy for dealing with old/unmaintained drivers
> here, if I can't get a response from driver authors?

fsl_elbc_nand uses this for historical reasons, to retain compatibility  
with the original OOB layout which only reserved one byte for the bad  
block marker and let users write to the second byte.  This controller  
only supports 8-bit chips.

See commit 97ae023648e764f794ffb9c52da109d6caf09c47

-Scott