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

Artem Bityutskiy dedekind1 at gmail.com
Mon Dec 12 07:48:58 EST 2011


On Wed, 2011-12-07 at 10:32 -0800, Mike Dunn wrote:
> Hi Ricard, thanks for chiming in.
> 
> On 12/07/2011 12:01 AM, Ricard Wanderlof wrote:
> >
> >
> > So, something like this:
> > - The driver reports number of bit flips and current ECC strength etc to
> >   the mtd layer.
> > - Based on some userspace knob, the mtd framework reports -EUCLEAN if
> >   scrubbing is needed.
> > - Upper layers perform scrubbing if they want to (i.e. UBI) or not (i.e.
> >   JFFS2).
> 
> 
> Sounds like a nice compromise between user configurability and keeping the
> decision in the mtd layer.  The problem is that the read method currently goes
> directly to the driver, so all drivers would have to be patched.  The last patch
> I submitted was rejected as being too large.  And it can't be broken into
> smaller patches because they are interdependent and not bisectable. 
> Implementing this scheme would be an even larger patch, and the changes made to
> every driver would bear scrutiny.

Yeah, I think it is OK.

1. Sanitize MTD interfaces by turning mtd->kuku(buh, buh) to
mtd_kuku(mtd, buh, buh). This should be easy to do - introduce wrappers
which just call mtd->kuku(buh, buh).

Then you can add your ECC stuff to mtd_*() functions.

Careful with partitions - we want ECC levels to be per-partition, so
that one could set different scrublevels for different partitions. So I
guess your ECC stuff should be in partition functions.

I do not remember off-the top of my head how it is handled nowadays, but
in the past, when we had mtdpart as a separate module, it was possible
to bypass partition wrappers. You should make it so that even if there
are no partitions - everything goes via mtpart anyways. Nowadays mtdpart
is an integral part of mtd, so this should be easy to do.

-- 
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/20111212/3cef807f/attachment-0001.sig>


More information about the linux-mtd mailing list