All of lore.kernel.org
 help / color / mirror / Atom feed
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 13:05:20 +0200	[thread overview]
Message-ID: <20170515130520.6ffff277@bbrezillon> (raw)
In-Reply-To: <f47ffee8-a40d-0fc1-65a7-99e1596ea9f0@nod.at>

On Mon, 15 May 2017 12:10:58 +0200
Richard Weinberger <richard@nod.at> wrote:

> Boris,
> 
> Am 15.05.2017 um 11:41 schrieb Boris Brezillon:
> >> 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.  
> 
> Hmm, I'm not sure whether it makes sense to be smart in this case.
> If somebody needs to fixup his bad blocks, like Mario described, there
> are no other users and such an action should only be done when you
> really know what you are doing.
> This is a debug knob and not a knob that should be used in production
> or while other parts of the chip are in use.

Fair enough. Let's keep it simple then.

  reply	other threads:[~2017-05-15 11:05 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
2017-05-15 10:10         ` Richard Weinberger
2017-05-15 11:05           ` Boris Brezillon [this message]
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=20170515130520.6ffff277@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.