Re: dangerous NAND_BBT_SCANBYTE1AND6

[Matthieu CASTET <matthieu.castet@parrot.com>]

Artem Bityutskiy a écrit :
> On Thu, 2011-04-21 at 19:10 +0200, Ivan Djelic wrote:
>> On Thu, Apr 21, 2011 at 04:52:59PM +0100, Matthieu Castet wrote:
>>> Hi,
>>>
>>> I believe NAND_BBT_SCANBYTE1AND6 behavior is very dangerous.
>>> We have a ST flash where ecc where but on bit 5 and 6.
>>> With new kernel all block are bad.
>>>
>>> Is this option is really needed ?
>>> ST datasheet say [1]. We already check the first Word.
>>> Why do we need to check the 6th Byte ?
>> I agree with Matthieu, NAND_BBT_SCANBYTE1AND6 code also seems wrong to me.
> 
> This just means that we need a better way for drivers to inform the
> generic code about how exactly blocks are marked as bad. Probably
> drivers could describe this with a data structure, and sometimes even
> provide a "is_block_bad()" function.
> 
> The options seem to be not enough.
> 
I think we should also unify bad block scanning.

In the current code bad block scanning could be done by :
- chip->block_bad (default nand_block_bad)
- nand_isbad_bbt


Why nand_isbad_bbt doesn't call chip->block_bad and implement its own scanning
code (scan_block_full or scan_block_fast) ?

This is bad because chip->block_bad can be modified by a driver, but
nand_isbad_bbt won't use it.

Also nand_block_bad and nand_isbad_bbt doesn't use the same scanning pattern.


Matthieu