public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Robert Jarzmik <robert.jarzmik@free.fr>
To: dedekind1@gmail.com, David Woodhouse <dwmw2@infradead.org>
Cc: Mike Dunn <mikedunn@newsguy.com>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	Ivan Djelic <ivan.djelic@parrot.com>
Subject: Re: [PATCH v2 07/16] mtd/docg3: add OOB layout to mtdinfo
Date: Sun, 13 Nov 2011 17:38:31 +0100	[thread overview]
Message-ID: <87ehxchta0.fsf@free.fr> (raw)
In-Reply-To: <1321191352.2273.14.camel@koala> (Artem Bityutskiy's message of "Sun, 13 Nov 2011 15:35:49 +0200")

Artem Bityutskiy <dedekind1@gmail.com> writes:

> What Robert says is that we probably need an is_page_blank() and let the
> driver implement it optimally, or make MTD fall-back to 0xFFs
> comparison.
>
> This is my understanding.
And that's exactly my point.

And while we're discussing MTD API, I'd like to add another thing I was thinking
of, from a conversation Mike and Ivan had.

They discussed how UBIFS is "intolerant" to bitflips, and marks a block as
"unusable" if one bitflip occured, even if the ECC can fix much more.

What I was thinking is that the MTD oob information which exposes how many ECC
are available should expose as well how many bitflips can be fixed (for example
4 bitflips can be fixed, 5 bitflips can be detected). Then, the read_oob()
function could return back 0 if read was successful, -Exxxx on error, or a
positive number N if N bitflips were fixed.
With this information, upper level could decide from (read_oob() return and
ecc.fixable_bitflips) if a block should be marked as unusable (worn out) or not.

I'd like some feedback on this idea as well.

Cheers.

--
Robert

  reply	other threads:[~2011-11-13 16:38 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-10  8:05 [PATCH v2 00/16] DocG3 fixes and write support Robert Jarzmik
2011-11-10  8:05 ` [PATCH v2 01/16] mtd/docg3: fix debug log verbosity Robert Jarzmik
2011-11-10  8:05 ` [PATCH v2 02/16] mtd/docg3: fix tracing of IO in writeb Robert Jarzmik
2011-11-10  8:05 ` [PATCH v2 03/16] mtd/docg3: fix protection areas reading Robert Jarzmik
2011-11-10  8:05 ` [PATCH v2 04/16] mtd/docg3: fix BCH registers Robert Jarzmik
2011-11-12 19:40   ` Mike Dunn
2011-11-13 10:20     ` Robert Jarzmik
2011-11-10  8:05 ` [PATCH v2 05/16] mtd/docg3: fix reading oob+data without correction Robert Jarzmik
2011-11-10  8:05 ` [PATCH v2 06/16] mtd/docg3: add multiple floor support Robert Jarzmik
2011-11-10  8:05 ` [PATCH v2 07/16] mtd/docg3: add OOB layout to mtdinfo Robert Jarzmik
2011-11-12 19:39   ` Mike Dunn
2011-11-13 10:18     ` Robert Jarzmik
2011-11-13 12:53       ` Artem Bityutskiy
2011-11-13 13:03         ` David Woodhouse
2011-11-13 13:35           ` Artem Bityutskiy
2011-11-13 16:38             ` Robert Jarzmik [this message]
2011-11-13 19:55               ` Mike Dunn
2011-11-13 20:27                 ` Artem Bityutskiy
2011-11-14 18:08                   ` Proposed change to mtd read functions (Was Re: [PATCH v2 07/16] mtd/docg3: add OOB layout to mtdinfo) Mike Dunn
2011-11-14 17:38                     ` Artem Bityutskiy
2011-11-14  0:58       ` [PATCH v2 07/16] mtd/docg3: add OOB layout to mtdinfo Mike Dunn
2011-11-10  8:05 ` [PATCH v2 08/16] mtd/docg3: add registers for erasing and writing Robert Jarzmik
2011-11-10  8:05 ` [PATCH v2 09/16] mtd/docg3: add OOB buffer to device structure Robert Jarzmik
2011-11-10  8:05 ` [PATCH v2 10/16] mtd/docg3: add write functions Robert Jarzmik
2011-11-10  8:05 ` [PATCH v2 11/16] mtd/docg3: add erase functions Robert Jarzmik
2011-11-10  8:05 ` [PATCH v2 12/16] mtd/docg3: map erase and write functions Robert Jarzmik
2011-11-10  8:05 ` [PATCH v2 13/16] mtd/docg3: add ECC correction code Robert Jarzmik
2011-11-12 19:49   ` Mike Dunn
2011-11-13 10:35     ` Robert Jarzmik
2011-11-14  2:13       ` Mike Dunn
2011-11-10  8:05 ` [PATCH v2 14/16] mtd/docg3: add suspend and resume Robert Jarzmik
2011-11-10  8:05 ` [PATCH v2 15/16] mtd/docg3: add fast mode Robert Jarzmik
2011-11-10  8:05 ` [PATCH v2 16/16] mtd/docg3: add protection areas sysfs access Robert Jarzmik
2011-11-12 20:02 ` [PATCH v2 00/16] DocG3 fixes and write support Mike Dunn
2011-11-13 10:41   ` Robert Jarzmik

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=87ehxchta0.fsf@free.fr \
    --to=robert.jarzmik@free.fr \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=ivan.djelic@parrot.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mikedunn@newsguy.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox