[PATCH v2] MTD: modify mtd api to return bitflip info on read operations

[Mike Dunn]

On 12/05/2011 09:09 AM, Peter Horton wrote:
> On 05/12/2011 16:58, Mike Dunn wrote:
>> On 12/04/2011 10:07 PM, Artem Bityutskiy wrote:
>>> On Sun, 2011-12-04 at 06:55 -0800, Mike Dunn wrote:
>>>> So you're thinking that the driver would supply both ecc_strength and
>>>> "scrublevel" (or maybe bb_threshold)?  Would these go into struct mtd_info?
>>> Probably yes. After all, UBI has no idea about what kind of flash is
>>> that and what kind of ECC it uses and what bit-flip level needs
>>> scrubbing. So I think this kind of information should come from the
>>> driver or from the user via mtd sysfs files. What do you think?
>>
>>
>> I'm not a flash expert, but that sounds reasonable, especially if the scrublevel
>> parameter is optional, with UBI using ecc_strength as the default value.  As for
>> how to pass the parameter, sysfs might be a good idea for scrublevel, allowing
>> it to be tunable without having to modify the driver if experience show that the
>> driver author's original assumptions about how a block degrades were incorrect.
>>
>
> Surely the check for "do we need to scrub ?" should be done lower down
> otherwise all users of the mtd NAND interface (UBI / JFFS2 etc) are going to
> have to re-implement those sysfs files and the corresponding checks.


Well, anything higher up that wants to avail itself of this api change will need
some rework regardless.  Currently the only info passed up from the driver is
that at least one bitflip occurred somewhere during the read.  The plan is to
eventually make some changes to UBI so that the decision to scrub is made more
intelligently.

Also, in addition to being too restricting, hard-coding the decision whether to
scrub into the driver would be tantamount to the driver setting policy, I think.

Thanks,
Mike