From: Artem Bityutskiy <dedekind1@gmail.com>
To: Mike Frysinger <vapier.adi@gmail.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: linux equivalent of u-boot's "nand scrub" (erasing blocks even when OOB says "bad")
Date: Thu, 23 Sep 2010 15:28:14 +0300 [thread overview]
Message-ID: <1285244894.29268.104.camel@localhost> (raw)
In-Reply-To: <201009220343.33025.vapier.adi@gmail.com>
On Wed, 2010-09-22 at 03:43 -0400, Mike Frysinger wrote:
> On Sunday, September 12, 2010 03:54:03 Artem Bityutskiy wrote:
> > On Sun, 2010-09-12 at 00:03 -0400, Mike Frysinger wrote:
> > > On Sat, Sep 11, 2010 at 02:32, Artem Bityutskiy wrote:
> > > > It will be confusing if the same word is used in MTD for "unmarking"
> > > > eraseblocks. How about: 'force erase' or 'bad erase' ?
> > >
> > > that makes it sound like an option to the existing MEMERASE operation.
> > >
> > > so i guess what if we just do that -- extend the erase_info_user
> > >
> > > structure to contain a flags field and add a MEMERASE2 that works with
> > > the larger structure ? for now we'd only have one option (FORCE), but
> > > it makes it easy to extend in the future.
> >
> > Ohh, this was so stupid of me to not ask people to add extra fields to
> > 'struct erase_info_user64' which was introduced relatively recently... I
> > always add extra fields to ioctl data structures...
> >
> > But yeah, what you say sounds ok to me.
>
> here's a POC that works for me. with a simple tweak to `flash_eraseall`, i
> can now recover my mtd devices with funky OOB layouts.
>
> ive only extended MEMERASE64 as i believe the non-64 variants are EOL ? or
> should i also extend the 32bit interface as well ?
We need something consistent. This patch will just erase the bad
eraseblock. This will not mark it as good in the BBT (neither in-ram nor
on-flash). If the erasure succeeds, the block will still be marked as
bad in BBT, but after reboot, if the BBT is not on-flash, it will be
treated as good eraseblock, because scanning will not find the bad block
marker anymore. If the BBT is on-flash, it'll stay bad. This is
inconsistent.
> +struct erase_info_user64_flags {
> + __u64 start;
> + __u64 length;
> + __u32 flags;
> +};
I think it needs to have som more room for possible future extentions.
Also, good tone for ioctls is to make them to be multiple of 64-bit -
less pain in mixed 32/64 bit setups.
Please, add some
u8 padding[12]
field and add a comment that this has to be zero, and may be used in
future.
Then in future we may extend ioctls and add more fields.
> +#define MEMERASE64_FLAGS _IOW('M', 23, struct erase_info_user64_flags)
I do not like the name. We may add something else, not just flags later.
May be MEMERASE64_EXTENDED ?
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
next prev parent reply other threads:[~2010-09-23 12:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-10 23:53 linux equivalent of u-boot's "nand scrub" (erasing blocks even when OOB says "bad") Mike Frysinger
2010-09-11 6:32 ` Artem Bityutskiy
2010-09-12 4:03 ` Mike Frysinger
2010-09-12 7:54 ` Artem Bityutskiy
2010-09-22 7:43 ` Mike Frysinger
2010-09-23 12:28 ` Artem Bityutskiy [this message]
2010-09-23 19:55 ` Mike Frysinger
2010-09-24 8:47 ` Artem Bityutskiy
2010-09-13 5:54 ` linux equivalent of u-boot's "nand scrub" (erasing blocks even whenOOB " Jon Povey
2010-09-13 6:25 ` Artem Bityutskiy
2010-09-14 1:16 ` Mike Frysinger
2010-09-14 1:53 ` Jon Povey
2010-09-14 1:59 ` 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=1285244894.29268.104.camel@localhost \
--to=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=vapier.adi@gmail.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.