Messages in this thread | | | From | Robert Jarzmik <> | Subject | Re: [PATCH v2 07/16] mtd/docg3: add OOB layout to mtdinfo | Date | Sun, 13 Nov 2011 17:38:31 +0100 |
| |
Artem Bityutskiy <dedekind1@gmail.com> writes:
> What Robert says is that we probably need an is_page_blank() and let the > driver implement it optimally, or make MTD fall-back to 0xFFs > comparison. > > This is my understanding. And that's exactly my point.
And while we're discussing MTD API, I'd like to add another thing I was thinking of, from a conversation Mike and Ivan had.
They discussed how UBIFS is "intolerant" to bitflips, and marks a block as "unusable" if one bitflip occured, even if the ECC can fix much more.
What I was thinking is that the MTD oob information which exposes how many ECC are available should expose as well how many bitflips can be fixed (for example 4 bitflips can be fixed, 5 bitflips can be detected). Then, the read_oob() function could return back 0 if read was successful, -Exxxx on error, or a positive number N if N bitflips were fixed. With this information, upper level could decide from (read_oob() return and ecc.fixable_bitflips) if a block should be marked as unusable (worn out) or not.
I'd like some feedback on this idea as well.
Cheers.
-- Robert
| |