From: Artem Bityutskiy <dedekind1@gmail.com>
To: Iwo Mergler <iwo@call-direct.com.au>
Cc: linux-mtd@lists.infradead.org, Mike Frysinger <vapier@gentoo.org>
Subject: Re: [PATCH] nandwrite: add --nobad to write bad blocks
Date: Wed, 29 Sep 2010 15:59:33 +0300 [thread overview]
Message-ID: <1285765173.2437.123.camel@localhost> (raw)
In-Reply-To: <4CA2B3E9.3030707@call-direct.com.au>
On Wed, 2010-09-29 at 13:35 +1000, Iwo Mergler wrote:
> The upshot of this is that blocks are marked as bad by the
> manufacturer based on corner case testing. Like erasing at
> high temperature / low voltage and reading back at low
> temperature / high voltage. The manufacturer can also
> access pads on the naked die that are not connected to pins
> during packaging.
Is only about letting you write to bad eraseblocks, not about erasing
them. I assumed this cannot be used for marking bad eraseblocks as good
back. The kernel does not have any protection against writing to bad
eraseblocks, so I do not see why Mike cannot have this option.
But speaking about erasing bad eraseblocks, which we also discussed, I
think you have a good point - we should probably distinguish between
factory-marked bad eraseblocks and user-marked. AFAIR, the OOB marker
for them was even different, or in BBT, do not really remember.
We probably can allow erasing user-marked bad eraseblocks and unmarking
them. But we probably should not allow erasing factory-marked bad
eraseblocks. But again, I'm not sure if it is possible to do, did not
really think about this.
But I think this particular patch from Mike is OK.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
next prev parent reply other threads:[~2010-09-29 13:01 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-12 3:51 [PATCH] nandwrite: add --nobad to write bad blocks Mike Frysinger
2010-09-12 16:27 ` Artem Bityutskiy
2010-09-12 19:05 ` Mike Frysinger
2010-09-13 6:23 ` Artem Bityutskiy
2010-09-14 1:21 ` Mike Frysinger
2010-09-14 5:26 ` Artem Bityutskiy
2010-09-22 4:23 ` Mike Frysinger
2010-09-22 7:12 ` Artem Bityutskiy
2010-09-22 7:34 ` Mike Frysinger
2010-09-29 3:35 ` Iwo Mergler
2010-09-29 6:56 ` Jon Povey
2010-09-29 13:25 ` Mike Frysinger
2010-09-29 23:44 ` Iwo Mergler
2010-09-30 3:23 ` Jon Povey
2010-09-29 12:59 ` Artem Bityutskiy [this message]
2010-09-29 13:28 ` Mike Frysinger
2010-09-30 3:51 ` Jon Povey
2010-09-23 1:48 ` Jon Povey
2010-09-23 10:38 ` Artem Bityutskiy
2010-09-23 20:04 ` [PATCH v2] " Mike Frysinger
2010-09-24 8:50 ` Artem Bityutskiy
2010-09-24 12:33 ` Mike Frysinger
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=1285765173.2437.123.camel@localhost \
--to=dedekind1@gmail.com \
--cc=iwo@call-direct.com.au \
--cc=linux-mtd@lists.infradead.org \
--cc=vapier@gentoo.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 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.