[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