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

[Artem Bityutskiy]

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.

> 
> > 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.

-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20111204/cae96ced/attachment.sig>