From: Vitaly Wool <vwool@ru.mvista.com>
To: "Juha Yrjölä" <juha.yrjola@nokia.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH] [JFFS2] Make NAND OOB usage more flexible
Date: Thu, 05 Jan 2006 16:29:49 +0300 [thread overview]
Message-ID: <43BD1F4D.6090000@ru.mvista.com> (raw)
In-Reply-To: <1136467206.22022.28.camel@two.research.nokia.com>
Hi Juha,
no, the latest patch is
http://lists.infradead.org/pipermail/linux-mtd/2005-December/014648.html.
It doesn't touch OneNAND but the required changes are so similar to
common NAND that I don't think it's gonna be a problem to extend it for
OneNAND. I just didn't bother to; but the approach itself is quite generic.
Vitaly
Juha Yrjölä wrote:
>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.
>>>
>>>
>
>
>
>
>
next prev parent reply other threads:[~2006-01-05 13:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-02 20:54 [PATCH] [JFFS2] Make NAND OOB usage more flexible Juha Yrjölä
2006-01-05 12:31 ` Vitaly Wool
2006-01-05 12:54 ` Artem B. Bityutskiy
2006-01-05 13:20 ` Juha Yrjölä
2006-01-05 13:29 ` Vitaly Wool [this message]
2006-01-06 2:20 ` zhao, forrest
2006-01-05 12:49 ` Artem B. Bityutskiy
2006-01-05 20:07 ` Todd Poynor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43BD1F4D.6090000@ru.mvista.com \
--to=vwool@ru.mvista.com \
--cc=juha.yrjola@nokia.com \
--cc=linux-mtd@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.