All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Steve Finney <saf76@earthlink.net>
Cc: linux-mtd@lists.infradead.org
Subject: Re: NAND OOB Questions...
Date: Tue, 06 Jun 2006 07:38:49 +0200	[thread overview]
Message-ID: <1149572330.11983.25.camel@localhost.localdomain> (raw)
In-Reply-To: <21148625.1149520632350.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net>

On Mon, 2006-06-05 at 08:17 -0700, Steve Finney wrote:
> >From: Thomas Gleixner <tglx@linutronix.de>
> >The buffer is usually 0xff except when a caller provides content.
> 
> I'm not going to repeat all the previous content, but from what you've said,
> it confirms that there is a bug in the current nand_base.c code under the following particular
> set of circumstances:
> 
> 1) A NAND flash that allows more than one cycle of writing between erases (at
>   least in the OOB area). (e.g., the Samsung K9F* chip).
> 2) Using hardware ECC (e.g., the Samsung S3C2410 processor).
> 3) A sequence in which you initially write to the device with ECC, and then
>   turn off ECC and do additional writes including the OOB area.
> 
> In the above sequence, the ECC the user writes to the OOB may get corrupted.

Yeah. I did not think about that abstruse scenario :) What the hell is
this for ?

> I  have an (ugly) user-level workaround: before I turn off the ECC, I write a 
> block that I know will generate ECC bytes consisting of 0xFF. Then the subsequent
> user ECC writes are OK.
> 
> It's obscure enough that it's probably not worth fixing (well, I'm not going to try to
> fix it :-) ),  and hopefully it's fixed in the refactoring. 

Should be.

	tglx

       reply	other threads:[~2006-06-06  5:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <21148625.1149520632350.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net>
2006-06-06  5:38 ` Thomas Gleixner [this message]
     [not found] <15200571.1149603155027.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net>
2006-06-06 15:03 ` NAND OOB Questions Thomas Gleixner
2006-06-01 16:38 Steve Finney
2006-06-05  8:14 ` Thomas Gleixner
2006-06-05  9:23   ` Charles Manning

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=1149572330.11983.25.camel@localhost.localdomain \
    --to=tglx@linutronix.de \
    --cc=linux-mtd@lists.infradead.org \
    --cc=saf76@earthlink.net \
    /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.