[RFC] nand_btt : use nand chip->block_bad

[Matthieu CASTET]

Hi,

Shmulik Ladkani a écrit :
> Hi,
> 
> On Fri, 29 Jun 2012 10:41:18 +0200 Matthieu CASTET <matthieu.castet at parrot.com> wrote:
>>> - The new scheme lacks the potential error correction offered by the
>>>   mtd_read_oob call (invoked from the original scan functions).
>>>   OTOH, currently, AFAIK, it is only offered by an out-of-tree driver.
>> Could you explain more here ?
>> The current scheme doesn't handle bitflip in bad block. We don't care about
>> error correction : bad block are not protected by ecc !
> 
> I was refering to utilizing the ECC when reading the OOB, so we won't
> get a false "bad" indication when reading the BBM from the OOB.
> 
> See this post (and subsequent ones):
> http://lists.infradead.org/pipermail/linux-mtd/2012-June/042203.html
> 
But oob is not protected by ecc in normal configuration. I believe more than 95%
of current configuration don't protect bad block with ecc.
Manufacturer bad block are also not protected by ecc.

How could this work ?
Do you have example of linux driver that protect bad block with ecc ?

Finally if there is a config with bad block protected by ecc, we can provide
another chip->block_bad callback which use ecc.


Also note that the post speak of "nand_chip.badblockbits" [1] which can be used
with this patch.


Matthieu

[1]
Because when ECC is available on OOB, it is good to utilize it, so
that bitflips don't cause good blocks to be marked bad. Less
importantly, when bad block markers are written by Linux (with ECC),
then these markers can be read back more reliably. (I note that there
is a nand_chip.badblockbits option that could theoretically alleviate
the first issue, but I see it is not actually implemented throughout
nand_bbt.c - only in nand_base.c)