All of lore.kernel.org
 help / color / mirror / Atom feed
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 (Артём Битюцкий)

  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 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.