[PATCH 1/8] mtd: nand: remove NAND_BBT_SCANBYTE1AND6 option

[Brian Norris]

On Wed, Oct 12, 2011 at 2:49 AM, Angus CLARK <angus.clark at st.com> wrote:
> Sorry to bring this up again, but I just thought you might be interested
> in the following clarification I received from Micron (who now own the
> ST/Numonyx NAND portfolio):

Nice to have a real manufacturer response.

> So, I believe this confirms your original interpretation of the
> ST/Numonyx datasheets and that the NAND_BBT_SCANBYTE1AND6 is valid.

I love being right :) But I feel this is really a matter of theory,
not practice.

> The
> question still remains what to do with this information, in view of the
> potential clash with existing ECC layouts (including the default S/W ECC
> layout).  A couple of options you proposed previously:

Just a memory recall: are the clashes only on 2KB page, 64B OOB
devices with "SCANBYTE1AND6" and certain ECC layouts? It's not an
issue with any small page (512B+16B) NAND with
NAND_SMALL_BADBLOCK_POS, is it? I suppose small page NAND uses smaller
ECC?

> 1) Retain the NAND_BBT_SCANBYTE1AND6 flag, and add some code to mask out
> the flag if necessary based on the ECC layout (possibly in
> nand_scan_tail()?).
>
> 2) Revert the flag, as done in this patch, and accept the very small
> possibility of missing some factory-marked bad-blocks.
>
> My preference would be 1), since it is technically correct, and would
> allow drivers to make use of the information if possible, while avoiding
> regressions associated with ECC layout clashes.

I thought (and still believe) that (1) is technically correct, but as
Micron states, it's not necessary. Option (2) is easier, and in my
experience, bad blocks are actually successfully written with all
zeros (whole block, not just the special OOB indicator). So really,
this is a matter of how much code should be added for an exception
that (arguably) provides no benefit.

> I appreciate the patch for 2) has already made it to l2-mtd2.6 so it may
> be too late anyway...

It's not too late, but even if we want to re-implement my patch, I
wouldn't recommend doing it exactly the same way. I think it was a
little ugly and could cause two consecutive writes to the same page,
which is sometimes a problem for newer flash (but may not be a problem
on the old flash to which this option would actually apply).

So I'm fine with leaving the code as it stands in l2-mtd-2.6. If
there's a consensus formed around reverting my revert, then I can
probably help, but I'm unlikely to take the initiative myself.

Brian