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

Shmulik Ladkani
2012-03-19T09:29:17Z

Hi Matthieu,

On Mon, 19 Mar 2012 09:50:54 +0100 Matthieu CASTET <matthieu.castet@parrot.com> wrote:
> > 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?
> > (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)
> No, they should return the worst case : max(total_corrected_per_page, ecc.strength).
> 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.

Thanks, your suggested heuristic is better than averaging.

However I guess you meant: min(total_corrected_per_page, ecc.strength)

My suggested 'ecc.read_page' retval denotes maximum bit errors per step.
As such, max possible return value is 'ecc.strength' (returning
'total_corrected_per_page' would be beyond max possible value).

'min(total_corrected_per_page, ecc.strength)' fits your suggestion to
prefer a false positive than having uncorrectable error.
It will indeed lead to scrubbing in "case 2".

Regards,
Shmulik