All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: linux-mtd@lists.infradead.org, Pekon Gupta <pekon@ti.com>
Subject: Re: [PATCH] mtd: nand_bbt: kill NAND_BBT_SCANALLPAGES
Date: Thu, 31 Oct 2013 12:32:43 -0300	[thread overview]
Message-ID: <20131031153242.GB1092@localhost> (raw)
In-Reply-To: <20131031152245.GB4700@norris.computersforpeace.net>

On Thu, Oct 31, 2013 at 11:22:45AM -0400, Brian Norris wrote:
> On Thu, Oct 31, 2013 at 07:20:39AM -0300, Ezequiel Garcia wrote:
> > On Wed, Oct 30, 2013 at 10:29:35PM -0400, Brian Norris wrote:
> > > Now that the last user of NAND_BBT_SCANALLPAGES has been removed, let's
> > > kill this peculiar BBT feature flag.
> > > 
> > 
> > I must admit I also find this option a bit puzzling.
> > 
> > However, I'm wondering what happens if a manufacturer specifies
> > the bad block mark is in some page at the middle of a block.
> > 
> > AFAIK, some of them do exactly that, and I've always thought
> > this option was the solution for such cases.
> 
> Well, it's not really a *good* solution for a marker in the middle of
> the page, as it's both inaccurate and heavily inefficient.

Granted.

> I've never heard of such a device. (There is a rare one or two that uses
> the 2nd-to-last or 3rd-to-last page.) Do you have any examples?
> 

Not at hand.

> > So, is this really no longer needed?
> 
> I think it just adds unnecessary complexity to nand_bbt.c. Generally,
> the fewer (unused) options the better. Also, this helps clear the way
> for some nand_base/nand_bbt simplification that I have planned.
> 
> Additionally, I think its only users were either accidental (in the case
> of omap2.c) or lazy (which didn't want to figure out the correct pages
> to scan for bad block markers). And now there are no users.
> 

Ok, agreed. But do we have any mechanism to scan a *particular*
page?

-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

  reply	other threads:[~2013-10-31 15:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-31  2:29 [PATCH] mtd: nand_bbt: kill NAND_BBT_SCANALLPAGES Brian Norris
2013-10-31 10:20 ` Ezequiel Garcia
2013-10-31 15:22   ` Brian Norris
2013-10-31 15:32     ` Ezequiel Garcia [this message]
2013-10-31 17:52       ` Brian Norris
2013-10-31 19:04 ` Ezequiel Garcia
2013-11-01  9:01   ` Artem Bityutskiy
2013-11-01 18:33     ` Brian Norris

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=20131031153242.GB1092@localhost \
    --to=ezequiel.garcia@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=pekon@ti.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.