From: Artem Bityutskiy <dedekind1@gmail.com>
To: David Peverley <pev@sketchymonkey.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
Ivan Djelic <ivan.djelic@parrot.com>,
Ricard Wanderlof <ricard.wanderlof@axis.com>
Subject: Re: CONFIG_MTD_NAND_VERIFY_WRITE with Software ECC
Date: Fri, 25 Feb 2011 15:21:49 +0200 [thread overview]
Message-ID: <1298640109.2798.110.camel@localhost> (raw)
In-Reply-To: <AANLkTikKe2ub8CZ+vP-1gXjtr=-BDJ6nc8aEG_9iJj6K@mail.gmail.com>
On Fri, 2011-02-25 at 12:59 +0000, David Peverley wrote:
> Hi All,
>
> > How about changing the MTD interface a little and teach it to:
> > 1. Report the bit-flip level (or you name it properly) - the amount of
> > bits flipped in this NAND page (or sub-page). If we read more than one
> > NAND page at one go, and several pages had bit-flips of different level,
> > report the maximum.
> This is important to allow the file-system to make an informed
> decision based on what happened within MTD. i.e. it would be able to
> ascertain whether a read corrected N bit errors and thus be able to
> re-program a block as required. I think is the only way to accomplish
> handling this at the FS level? However, given that the count comes
> from a specific read operation, I think it would need to be
> implemented as part of the read call e.g. passing in something like
> "unsigned *bit_errors"? This would mean changing something fundamental
> or providing a new API to read with this extra parameter so I'm not
> sure how this could be accomplished 'nicely'...
I do not think it is an issue - changing in-kernel API is relatively
easy and straight-forward task.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
next prev parent reply other threads:[~2011-02-25 13:23 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-15 12:35 CONFIG_MTD_NAND_VERIFY_WRITE with Software ECC David Peverley
2011-02-15 13:02 ` Ricard Wanderlof
2011-02-15 14:00 ` David Peverley
2011-02-15 15:01 ` Ricard Wanderlof
2011-02-15 17:58 ` David Peverley
2011-02-17 10:04 ` Ricard Wanderlof
2011-02-25 8:42 ` Artem Bityutskiy
2011-02-25 9:09 ` Ricard Wanderlof
2011-02-25 10:29 ` Artem Bityutskiy
2011-02-25 11:36 ` Ivan Djelic
2011-02-25 12:12 ` Artem Bityutskiy
2011-02-25 12:59 ` David Peverley
2011-02-25 13:21 ` Artem Bityutskiy [this message]
2011-02-25 18:27 ` Ivan Djelic
2011-02-25 14:44 ` Ivan Djelic
2011-02-25 16:41 ` Artem Bityutskiy
2011-02-25 12:22 ` Artem Bityutskiy
2011-02-25 15:14 ` Ivan Djelic
2011-02-25 8:31 ` Artem Bityutskiy
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=1298640109.2798.110.camel@localhost \
--to=dedekind1@gmail.com \
--cc=ivan.djelic@parrot.com \
--cc=linux-mtd@lists.infradead.org \
--cc=pev@sketchymonkey.com \
--cc=ricard.wanderlof@axis.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 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.