All of lore.kernel.org
 help / color / mirror / Atom feed
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.
>>>      
>>>
>
>
>
>  
>

  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.