[PATCH] [JFFS2] Make NAND OOB usage more flexible
Juha Yrjölä
juha.yrjola at nokia.com
Thu Jan 5 08:20:06 EST 2006
Hi Vitaly,
Sorry, I wasn't aware of any patch; I just joined the list. Is this the
patch?
http://lists.infradead.org/pipermail/linux-mtd/2005-December/014521.html
If it is, it seems to be ignorant of at least OneNAND.
However, I do agree that the OOB stuff is not handled well at all in the
current code (even after my patch). When you come up with a better
version, please update the OneNAND code, too.
As a side note, on OneNAND it'd actually probably be faster to do a one
big write of 64 OOB bytes instead of a lot of 2- or 3-byte writes.
Looks like your patch is paving way for this by moving the OOB handling
lower, which is good.
So I do agree that for the long term the OOB handling needs rework, but
my patch is a stopgap measure that allows all the devices (NAND and
OneNAND) to work right now.
BTW, this patch is bad:
http://lists.infradead.org/pipermail/linux-mtd/2005-December/014522.html
APIs visible to user-space should _never_ be broken if it's possible to
avoid it. You should implement a backwards-compatibility layer instead
of just removing the old ioctls.
Cheers,
Juha
On Thu, 2006-01-05 at 15:31 +0300, ext Vitaly Wool wrote:
> Oh my goodness... Maybe just apply my patch for OOB handling and all
> that stuff will go away?
>
> Vitaly
>
> Juha Yrjölä wrote:
>
> >Many (if not all) OneNAND devices have the free OOB bytes scattered
> >around the whole OOB area in blocks of 2 or 3 bytes. To work around
> >this, the JFFS2 wbuf code needs to consider _all_ the free OOB bytes
> >specified by the oobfree array.
More information about the linux-mtd
mailing list