[PATCH] mtd: nand: ignore ecc errors during bbt reads

[Brian Norris]

On 06/10/2012 11:41 PM, Shmulik Ladkani wrote:
> Thanks Brian for your comments,

You're welcome. And thanks for the interest in reviewing the code. Few 
people actually delve into nand_bbt.c, it seems :)

> On Sun, 10 Jun 2012 22:45:50 -0700 Brian Norris<computersforpeace at gmail.com>  wrote:
>>> Why not use 'MTD_OPS_RAW' in 'scan_block_fast()' as well (as done in
>>> 'scan_block_full')?
>>
>> 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.
>
> Ok (due to the second reason, as we're discussing the BBM read
> implementation).

I guess I worded my 'first' reason a little wrong. I meant: so that 
bitflips don't cause good blocks (0xff) to be read as bad blocks 
(bitflip => non-0xff). I think this would be far more significant, as a 
single bitflip in the BBM byte could cause errors.

>> So, I can send a patch that straightens out naming and brings
>> scan_block_fast() and scan_block_full() into alignment on using
>> MTD_OPS_PLACE_OOB. Then I think that we should continue using this
>> code in both:
>>                  /* Ignore ECC errors when checking for BBM */
>>                  if (ret&&  !mtd_is_bitflip_or_eccerr(ret))
>
> Sounds reasonable.

OK, I'll do that this week.

>> And we can (as agreed previously?) avoid using/checking max_bitflips
>> in mtd_read_oob(), although there is the datbuf+oob case that calls
>> nand_do_read_ops...
>
> This is a separate thing that needs to be addressed.
> See my findings in [1].

Right, I saw both threads kinda simultaneously. It looks like Mike may 
need to add some max_bitflips logic to mtd_read_oob after all.

Brian