[PATCH 0/3] MTD: Change meaning of -EUCLEAN return code on reads

[Mike Dunn]

On 03/19/2012 01:50 AM, Matthieu CASTET wrote:
> Hi,
> 
> Shmulik Ladkani a écrit :
>> Hi Mike,
>>
> 
>> The only immediate blocker for such a scheme would be those nand
>> controller drivers, where the controller is responsible of the ECC
>> correction, and it does not report per-step stats to the software.
>> Are there any?


I didn't get Shmulik's original email for some reason, only what was quoted in
Matthieu's.  I think the answer to this question is no.  There is one driver,
fsl_elbc_nand.c, that fits this description; i.e., detection, correction, and
stats reporting are all done in hardware, and it looks like the hardware can
only report that some corrections occurred, not the exact number.  Ecc can be
done in multiple steps (depending on page size). but because ecc.strength==1, we
only need to know if any corrections were made at all in order to report
bitflips on a per ecc step basis.  I don't believe there are any other drivers
where bitflips per step can not be determined.


>> (In that case, we have nothing else to do besides falling back to a
>> per-page decision. For example, such driver's 'read_page' may return
>> total_corrected_per_page/ecc.steps as an estimate of the number of
>> per-step corrected bits, or alike)


A compromise between max_bitflips per page vs per ecc step?  As Matthieu and
Ivan pointed out, you can still have a hard error and be under the threshold.


> No, they should return the worst case : max(total_corrected_per_page, ecc.strength).


I don't quite understand that.


> Otherwise you have the same problem : case 2 in [1] will fail.
> It is better to trigger false positive (do scrubbing) than having uncorrectable
> error.


I agree.

Thanks,
Mike