From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: Angus CLARK <angus.clark@st.com>,
linux-mtd@lists.infradead.org, dwmw2@infradead.org
Subject: Re: mtd nand erase and bad block
Date: Fri, 15 Jun 2012 00:31:21 +0300 [thread overview]
Message-ID: <20120615003121.214a871c@halley> (raw)
In-Reply-To: <CAN8TOE_47JHHakwHYApZhOgb72dQxk7f1bxMoN5kb6NaxnqZBg@mail.gmail.com>
Hi,
On Thu, 14 Jun 2012 10:48:49 -0700 Brian Norris <computersforpeace@gmail.com> wrote:
> On Tue, Jun 5, 2012 at 5:17 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> > On Fri, 2012-06-01 at 17:54 +0300, Shmulik Ladkani wrote:
> >>
> >> My personal preference would be:
> >> 1. A new ioctl (MEMSCRUB?)
> >> 2. debugfs flag, PER MTD PART (slightly safer than your global flag)
> >> 3. global debugfs flag
> >>
> > Yes, I guess option 1 is the best I think. Option 2 needs too much work.
>
>
> FWIW, a similar topic was brought up a long time back, with little result:
> http://lists.infradead.org/pipermail/linux-mtd/2010-October/032577.html
Thanks Brian for spotting this post.
It made me rethink of the MEMSCRUB suggestion and notice it is somewhat
limited.
I guess the main reason for erasing a block marked bad is to erase its
BBM (that was previously set for test purposes), so that the block will
no longer be considered bad.
But that would only work if BBM is the only bad-block identification
scheme (no on-flash BBT).
Hence the post by Jon Povey is actually better, as it provides a tiny
but useful building block: allow "scrubbing" the bad indication of
an erase-block. For a pure-BBM systems, that would be erasure of the
block; For pure flash-BBT, that would be updating the BBT; For systems
that update both BBM and BBT, we'll do both.
What do you think?
Regards,
Shmulik
next prev parent reply other threads:[~2012-06-14 21:31 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-31 12:12 mtd nand erase and bad block Matteo Facchinetti
2012-05-31 13:28 ` Adrian Hunter
2012-05-31 14:28 ` Matteo Facchinetti
2012-05-31 19:57 ` Shmulik Ladkani
2012-06-01 6:24 ` Adrian Hunter
2012-06-01 6:37 ` Ricard Wanderlof
2012-06-01 8:29 ` Angus CLARK
2012-06-01 8:42 ` Artem Bityutskiy
2012-06-01 11:04 ` Shmulik Ladkani
2012-06-01 14:03 ` Angus CLARK
2012-06-01 14:54 ` Shmulik Ladkani
2012-06-01 15:28 ` Angus CLARK
2012-06-05 12:17 ` Artem Bityutskiy
2012-06-14 17:48 ` Brian Norris
2012-06-14 21:31 ` Shmulik Ladkani [this message]
2012-06-15 6:55 ` Angus CLARK
2012-06-26 22:10 ` Tomer Barletz
2012-06-18 9:34 ` Angus CLARK
2012-06-27 9:54 ` Artem Bityutskiy
2012-06-27 12:37 ` Angus CLARK
2012-06-29 10:31 ` Artem Bityutskiy
2012-07-02 7:14 ` Angus CLARK
2012-07-03 12:22 ` Artem Bityutskiy
2012-07-03 15:05 ` Angus CLARK
2012-07-16 14:37 ` 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=20120615003121.214a871c@halley \
--to=shmulik.ladkani@gmail.com \
--cc=angus.clark@st.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).