Messages in this thread |  | | | Subject | Re: [PATCH v2 07/16] mtd/docg3: add OOB layout to mtdinfo | | From | David Woodhouse <> | | Date | Sun, 13 Nov 2011 13:03:18 +0000 |
| |
On Sun, 2011-11-13 at 14:53 +0200, Artem Bityutskiy wrote: > On Sun, 2011-11-13 at 11:18 +0100, Robert Jarzmik wrote: > > I personally think this should be provided by the MTD API. A function > > is_page_blank(ofs) could tell if the page was written or not. Now if the > > function is NULL, the upper layer (UBIFS, ...) could decide _by itself_ to > > assign a free OOB byte to that meaning. But IMHO it's not the drivers duty to > > take these decisions to restrict the OOB, let it be done at an upper level. > > Probably it is a good idea to introduce an mtd_is_page_blank. But it > should either work for all flashes or not introduced at all. I do not > think upper layers should use OOB at all. And this interface should also > work for NOR flash. Probably it should just fall-back to comparing the > data with 0xFF if the driver cannot offer anything special.
We *tried* comparing with 0xFF in JFFS2 and found that it wasn't good enough (it could be *mostly* erased before a powerfail but not completely, so as soon as you start to program it you get a lot of bitflips). Hence the cleanmarkers.
The only way you can treat a page as erased is if you *know* it was successfully erased. So I'd be reluctant to introduce a function that encourages people to draw inferences they shouldn't.
-- dwmw2 [unhandled content-type:application/x-pkcs7-signature] |  |