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

[Mike Dunn]

On 12/04/2011 06:43 AM, Artem Bityutskiy wrote:
> On Sun, 2011-12-04 at 05:52 -0800, Mike Dunn wrote:
>> On 12/04/2011 12:43 AM, Peter Horton wrote:
>>> On 03/12/2011 20:20, Mike Dunn wrote:
>>>> This patch proposes a change to the mtd API for the purpose of returning to
>>>> the caller information on the number of bit errors corrected by the ecc
>>>> facilities of the device during read operations.  The affected functions are
>>>> read() and read_oob().
>>>>
>>> Do the number of bit-flips mean anything to the higher layers like UBI? 
>>
>> The change was motivated primarily by the desire to get ubifs working well on
>> nand flash.  Currently it works well only on onenand devices where single
>> bitflips are rare and random.  On nand with frequent and consistent bitflips,
>> ubi marks a large portion of the blocks as "bad".
> Well, I think non-onenands are also supported. The very modern NAND
> support has issues because of new problems which did not exist or were
> not visible in the past.


I stand corrected.  Not intended as a knock on UBI :)


>>> As the ECC strength / error rate are a chip dependent thing how do the higher
>>> layers know what is good/normal/bad?
>>
>> Good point.  To be determined.  Probably just another element in the mtd_info
>> struct named ecc_strength or some such.  UBI e.g., can determine a suitable
>> "scrublevel" based on that.
> I think UBI should scrub only if max_bitflips == ecc_strength by
> default. If the driver supplies scrublevel scrub if max_bitflips ==
> scrublevel.


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?

Thanks,
Mike