mtd nand erase and bad block

[Shmulik Ladkani]

Hi,

On Fri, 01 Jun 2012 11:42:01 +0300 Artem Bityutskiy <dedekind1 at gmail.com> wrote:
> On Fri, 2012-06-01 at 09:29 +0100, Angus CLARK wrote:
> > I have to do this regularly for testing new NAND drivers.  After getting fed up
> > with doing temporary hacks all the time, I ended up adding a
> > 'nand_erasebadblock' entry to debugfs, which overrides the check in
> > nand_erase_nand():
> > ...
> > 	if (!nand_erasebadblock &&
> > 	    nand_block_checkbad(mtd, ((loff_t) page) <<
> > 				chip->page_shift, 0, allowbbt)) {
> > ...
> > 
> > The sequence in userspace would then be something like:
> > 
> > 	target% echo 1 > /sys/kernel/debug/nand_erasebadblock
> > 	target% flash_erase -N /dev/mtd6 0x00200000 1
> > 	target% echo 0 > /sys/kernel/debug/nand_erasebadblock
> > 

> > 
> > Typically, debugfs is only enabled in development environments, and even then it
> > requires explicit user action, so this method of enabling erasing bad blocks is
> > safe enough for our needs.
> 
> Sounds ok to me, especially if you send the patch together with a piece
> of doc for the mtd web-site. I just think it is important to document
> this feature. Is this doable?

I think we should prefer a local "allow erase bad blocks" policy than a
global one.

This is because when the global debugfs flag is on, *every* mtd erase
operation might lead to erasure of bad blocks - not necessarily those
triggered by the user which set the flag prior issuing his 'flash_erase'
command.

Meaning, other MTD users (ubi, various ffs) which currently work on
other mtd partitions, are suddenly relaxed and allowed to erase bad
blocks - which is probably not what user intented.

I suggest to be more restrictive and have the "allow erase bad blocks"
propery be local policy, that is - per an erase request.

And since we'll probably need this thing only for userspace erase
calls (e.g. flash_erase) - I suggest placing it into the MEMERASE ioctl.

Comments?

Regards,
Shmulik