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
next prev parent 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