From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Richard Weinberger <richard@nod.at>
Cc: "Mario J. Rugiero" <mrugiero@gmail.com>,
Marek Vasut <marex@denx.de>,
Cyrille Pitchen <cyrille.pitchen@atmel.com>,
Brian Norris <computersforpeace@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
linux-mtd@lists.infradead.org
Subject: Re: [PATCH v3] mtd: nand: add option to erase NAND blocks even if detected as bad.
Date: Mon, 15 May 2017 11:41:59 +0200 [thread overview]
Message-ID: <20170515114159.655309cf@bbrezillon> (raw)
In-Reply-To: <c373f192-99b2-2357-5c6b-dbc585b08169@nod.at>
On Mon, 15 May 2017 11:23:55 +0200
Richard Weinberger <richard@nod.at> wrote:
> Boris,
>
> Am 15.05.2017 um 10:21 schrieb Boris Brezillon:
> > #ifndef statements should be at the beginning of the line. But anyway,
> > I think we all agree that always forcing bad block erasure is a bad
> > idea. If we accept to support this feature, this should be done through
> > a per-NAND-chip debugfs entry, with fine grained selection of the block
> > that we're allowing to be forcibly erased.
> >
> > Here is a suggestion:
> >
> > echo all > /sys/kernel/debug/nand/<nand-chip-name>/erase-bad-blocks
> > echo none > /sys/kernel/debug/nand/<nand-chip-name>/erase-bad-blocks
> > echo X,Y-Z,... > /sys/kernel/debug/nand/<nand-chip-name>/erase-bad-blocks
> >
> > where X is an eraseblock number, and X-Y is a range of eraseblocks.
>
> Will a write to that file trigger the erase or just allow it?
Just allows it.
>
> IMHO we can keept it simple such as:
> echo y > /sys/kernel/debug/nand/<nand-chip-name>/allow-bad-block-erase
>
> Then a user can erase whatever he wants...
Well, I was proposing to do that because several users can use the same
NAND chip in parallel, and allowing to forcibly erase a bad block at
the NAND chip level can be dangerous in this case.
Here is a real example: 2 users are accessing 2 different partitions,
one wants to force bad block erasure on partition 1, while the other
just wants to normally erase partition 0. With the global
"allow/disallow bad block erasure" approach, you're just likely to
erase bad blocks in partition 0 as well.
>
> > BTW, maybe we should create and expose a top-level mtd debugfs directory
> > to avoid exposing MTD related things at the root of the debugfs FS.
> >
> > Something like:
> >
> > /sys/kernel/debug/mtd/<dev-type>/...
> >
> > so for the NAND related bits it would be
> >
> > /sys/kernel/debug/mtd/nand/...
>
> Yes, this makes sense to me.
>
> And since this is debugfs we can do what we want.
Yep.
next prev parent reply other threads:[~2017-05-15 9:42 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-12 5:39 [PATCH] mtd: nand: add option to erase NAND blocks even if detected as bad Mario J. Rugiero
2017-05-12 5:52 ` [PATCH v2] " Mario J. Rugiero
2017-05-12 7:39 ` [PATCH v3] " Mario J. Rugiero
2017-05-15 8:21 ` Boris Brezillon
2017-05-15 9:23 ` Richard Weinberger
2017-05-15 9:41 ` Boris Brezillon [this message]
2017-05-15 10:10 ` Richard Weinberger
2017-05-15 11:05 ` Boris Brezillon
2017-05-15 13:16 ` Mario Rugiero
2017-05-15 13:20 ` Boris Brezillon
2017-05-12 8:12 ` [PATCH] " Richard Weinberger
2017-05-12 8:16 ` Mario Rugiero
2017-05-12 8:24 ` Boris Brezillon
2017-05-12 8:33 ` Richard Weinberger
2017-05-12 8:44 ` Boris Brezillon
2017-05-12 8:45 ` Richard Weinberger
2017-05-12 8:34 ` Mario Rugiero
2017-05-12 8:45 ` Boris Brezillon
[not found] ` <CAKKQwLQueea6G4B-cng9QdpjtRWyBWHw1Mq9ai3DVp31xswANg@mail.gmail.com>
2017-05-12 9:02 ` Boris Brezillon
2017-05-12 9:15 ` Mario Rugiero
2017-05-12 9:16 ` Mario Rugiero
2017-05-12 9:32 ` Boris Brezillon
2017-05-12 9:19 ` Richard Weinberger
2017-05-12 9:26 ` Mario Rugiero
2017-05-12 9:34 ` Boris Brezillon
2017-05-12 10:06 ` Mario Rugiero
2017-05-12 10:19 ` Boris Brezillon
2017-05-12 10:23 ` Mario Rugiero
2017-05-12 10:34 ` Mario Rugiero
2017-05-13 9:17 ` Richard Weinberger
2017-05-15 2:54 ` Mario Rugiero
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=20170515114159.655309cf@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=cyrille.pitchen@atmel.com \
--cc=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marex@denx.de \
--cc=mrugiero@gmail.com \
--cc=richard@nod.at \
/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.