[PATCH] [MTD] [NAND]: nand_default_mark_blockbad() doesn't work when flash-based bbt not enabled

[Ricard Wanderlof]

On Fri, 20 Oct 2006, Artem Bityutskiy wrote:

> On Fri, 2006-10-20 at 17:36 +0200, Ricard Wanderlof wrote:
>>   		ofs += mtd->oobsize;
>> -		chip->ops.len = 2;
>> +		chip->ops.ooblen = 2;
>>   		chip->ops.datbuf = NULL;
>>   		chip->ops.oobbuf = buf;
>>   		chip->ops.ooboffs = chip->badblockpos & ~0x01;
>
> What is len and ooblen? Who initializes len then? I see len is used
> later on.

As I understand it, ops.len is the length of the ops.datbuf, and 
ops.ooblen is the length of the ops.oobbuf. In this case, we want to write 
two zeros to the OOB area, so we want to set ops.ooblen to 2, not ops.len. 
This is the way the function nand_fill_oob, further on in the call chain, 
expects to find the length of the data.

Hm, looking more carefully in the next function called, nand_do_write_oob, 
len _is_ used, however, I'm not sure that is correct. It is used in three 
cases, first in a debug printout (which incidentally displays the wrong 
function name), in a sanity check, and finally to set the return value. If 
you look at nand_fill_oob (called from nand_do_write_oob) it uses (only) 
ops.ooblen as the length counter. chip->ecc.write_oob is by default 
nand_write_oob_std, and always writes the whole oob area.

While testing the patch, I put some debugging printouts in nand_fill_oob. 
I could see other cases where it was being called correctly, i.e. with 
ops.ooblen set, e.g. when writing JFFS2 cleanmarkers. So I'm assuming that 
it is ops.ooblen that should be set, and that the references to ops.len in 
this call chain are not correct.

I'll test this on Monday when I get back to work; I don't have access to a 
machine to test on right now.

/Ricard
--
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30