[PATCH 1/2] nand: nand_bbt: Export nand_update_bbt

[Brian Norris]

Hi,

>From Artem: "Why this driver redefined ->block_markbad() at all, it is
not supposed
to do this. We should fix the driver instead."

Why is ->block_markbad() a function pointer, then, if the driver is
not allowed to redefine it? Admittedly, it often doesn't make sense to
override it; plus, if you override ->block_markbad(), you probably
want to also override ->block_bad(). But nand_base.c doesn't really
have good infrastructure for that.

So, by the current, somewhat messy and incomplete state of the
nand_base + nand_bbt code, it seems to be "supported" to override
->block_markbad() if you really need to. But some more work could be
done to improve this.

On Fri, Aug 24, 2012 at 3:35 AM, Huang Shijie <b32955 at freescale.com> wrote:
> 于 2012年08月24日 14:41, Artem Bityutskiy 写道:
>
>> The default function seem to do the same as your function does. You
>> select where you keep your OOB using chip options, and the default
>> function does the right thing, no?
>
> I don't think the default function do the same thing. You see:
>   nand_default_block_markbad() --> nand_do_write_oob() -->
> chip->ecc.write_oob() -->gpmi_ecc_write_oob()
>
> The gpmi_ecc_write_oob() does nothing,but return -EPERM.

Yeah, that's kind of strange. So you never have room in OOB even for
bad block markers? How do you identify factory-marked bad blocks?
Wouldn't they be indistinguishable from your ECC area? Or do you have
free OOB space in which you could actually implement write_oob()
properly?

None of my comments are really a disagreement with your patch. Your
driver has a strange way of dealing with ECC + bad block markers, and
assuming you figured out your swap_block_mark code safely (I didn't
really study this) then I think it's OK ("supported") to provide your
own ->block_markbad() function.

Brian