From: Artem Bityutskiy <dedekind1@gmail.com>
To: Jon Povey <jon.povey@racelogic.co.uk>
Cc: Mike Frysinger <vapier@gentoo.org>,
linux-mtd@lists.infradead.org, Brian Norris <norris@broadcom.com>
Subject: Re: [RFC] mtd: add MEMSETGOODBLOCK ioctl
Date: Tue, 12 Oct 2010 12:02:57 +0300 [thread overview]
Message-ID: <1286874177.2164.14.camel@localhost> (raw)
In-Reply-To: <1286335318-17542-1-git-send-email-jon.povey@racelogic.co.uk>
On Wed, 2010-10-06 at 12:21 +0900, Jon Povey wrote:
> Adds the MEMSETGOODBLOCK ioctl, inverse operation of MEMSETBADBLOCK for
> times when you really are sure that a block is good, but was marked bad
> in error.
>
> WARNING: This ioctl should not be casually used, you can't magically
> fix unreliable blocks, and causing the system to try and use them may
> cause you problems. Manufacturer-marked bad blocks may be forgotten
> and impossible to find again later. Be careful.
>
> This ioctl is for situations where you know what you are doing, for
> example your bootloader has to be written with a different OOB layout
> and scanned as bad when the BBT was generated, but you know it's good
> and want to rewrite it from Linux.
>
> Signed-off-by: Jon Povey <jon.povey@racelogic.co.uk>
> ---
> This is a request for comment on this approach to bad blocks, this patch
> only considers the nand driver and only versions with a BBT on flash.
>
> This works for me on davinci DM355 with 2K page NAND flash.
>
> drivers/mtd/mtdchar.c | 13 +++++++++
> drivers/mtd/mtdpart.c | 18 ++++++++++++
> drivers/mtd/nand/nand_base.c | 60 ++++++++++++++++++++++++++++++++++++++++++
> include/linux/mtd/mtd.h | 1 +
> include/linux/mtd/nand.h | 2 +
> include/mtd/mtd-abi.h | 1 +
> 6 files changed, 95 insertions(+), 0 deletions(-)
Briefly looked - you do not have any locking. You should have some
nand_get_device() calls.
Also, did you investigate whether it is possible to distinguish between
factory-marked bad eraseblocks and user-marked bad eraseblocks?
Also, if this patch to go in, I'd really like to see some Reviewed-by
and Tested by. Or some good list of setups where you tested this
yourself and how you did this. Is this possible?
Let's CC Mike who was interested in this and Brian who was doing great
job in the BBT area recently and could review this patch.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
next prev parent reply other threads:[~2010-10-12 9:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-06 3:21 [RFC] mtd: add MEMSETGOODBLOCK ioctl Jon Povey
2010-10-12 9:02 ` Artem Bityutskiy [this message]
2010-10-12 9:24 ` Jon Povey
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=1286874177.2164.14.camel@localhost \
--to=dedekind1@gmail.com \
--cc=jon.povey@racelogic.co.uk \
--cc=linux-mtd@lists.infradead.org \
--cc=norris@broadcom.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox