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

[Scott Wood <scottwood@freescale.com>]

On 09/26/2012 05:43:35 PM, Brian Norris wrote:
> On Mon, Sep 17, 2012 at 6:28 PM, Scott Wood <scottwood@freescale.com>  
> wrote:
> > On 09/17/2012 08:06:54 PM, Brian Norris wrote:
> >> On Mon, Aug 6, 2012 at 3:21 PM, Brian Norris  
> <computersforpeace@gmail.com> wrote:
> ...
> >> 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.
> 
> OK. Could this be fixed up by forcing nand_chip.badblockpos=0 in
> fsl_elbc_nand? I think nand_base/nand_bbt are configured to read/write
> only a single byte for 8-bit chips now.

Good, in that case I think we can just drop it.  No need to override  
nand_chip.badblockpos; it's only the size that we were overriding.

> > See commit 97ae023648e764f794ffb9c52da109d6caf09c47
> 
> I can't find such a commit in upstream. Perhaps you're referring to a
> private git tree?

Oops, that was the U-Boot tree. :-P

The Linux commit is 452db2724351ff3d9416a183a7955e00ab4e6ab4

-Scott