[RFC] mtd: nand: separate chip options / bbt_options

[Brian Norris]

Hi,

Again, sorry for the wait time on this. I've been busy. Now I'm
addressing most of these topics and will send a patch soon. I haven't
completely answered the following question, though.

On Fri, Apr 22, 2011 at 1:02 AM, Artem Bityutskiy <dedekind1 at gmail.com> wrote:
> On Wed, 2011-04-20 at 00:13 -0700, Brian Norris wrote:
>> Other things to consider (not yet implemented):
>> * Is it safe to move NAND_CREATE_EMPTY_BBT to bbm.h and require it to be
>>   put in bbt_options? It seems not to be used by any in-kernel drivers
>>   so it's only likely to mess with independent drivers...
>
> What exactly this option mean and how could it be used?

I'm not entirely sure how it would be used (perhaps ask Sebastian, the
one who introduced it in commit 453281a9), but I have an idea what it
means.

It seems that (when combined with NAND_BBT_CREATE) this flag causes
nand_scan_bbt() / check_create() to skip the scanning portion of
creating a bad block table, effectively leaving an empty bad block
table. According to the commit message:
    it will create an empty BBT table without considering vendor's BBT
    information. Vendor's information may be unavailable if the NAND
    controller has a different DATA & OOB layout or this information may be
    allready purged.

I'm prepared to simply move this over to bbm.h (next to
NAND_BBT_CREATE) if it's worth saving. Otherwise, it can just as
easily be dumped.

Brian