All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
To: Matthieu CASTET <matthieu.castet@parrot.com>
Cc: Brian Norris <computersforpeace@gmail.com>,
	linux-mtd@lists.infradead.org
Subject: Re: [RFC] nand_btt : use nand chip->block_bad
Date: Thu, 28 Jun 2012 21:31:46 +0300	[thread overview]
Message-ID: <20120628213146.7d929204@halley> (raw)
In-Reply-To: <1340898442-1585-1-git-send-email-matthieu.castet@parrot.com>

Hi Matthieu,

On Thu, 28 Jun 2012 17:47:22 +0200 Matthieu CASTET <matthieu.castet@parrot.com> wrote:
>  	for (i = startblock; i < numblocks;) {
>  		int ret;
>  
>  		BUG_ON(bd->options & NAND_BBT_NO_OOB);
>  
> -		if (bd->options & NAND_BBT_SCANALLPAGES)
> -			ret = scan_block_full(mtd, bd, from, buf, readlen,
> -					      scanlen, len);
> -		else
> -			ret = scan_block_fast(mtd, bd, from, buf, len);
> -
> +		ret = this->block_bad(mtd, from, 1);
>  		if (ret < 0)
>  			return ret;
>  

Hmm, seems elegant, nand_bbt is not supposed to be elegant, what are we
missing here? ;-))

- I think nand_chip ops are not supposed to be called directly from
  outside nand driver (nand_base et al); instead the mtd interfaces
  should be used.
  OTOH, one might consider nand_bbt to be part of nand_base driver...

- The new scheme lacks the potential error correction offered by the
  mtd_read_oob call (invoked from the original scan functions).
  OTOH, currently, AFAIK, it is only offered by an out-of-tree driver.

- The original scheme allows validating against an arbitrary
  nand_bbt_descr, whereas 'block_bad' reads the 'badblockpos' byte.
  Don't know if this is a real issue (need to look at the descriptors
  used); and probably, 'block_bad' can be augmented to use a given
  descriptor.

- To preserve all functionality, we need to augment 'block_bad'
  implementors to support NAND_BBT_SCANALLPAGES (e.g. nand_block_bad
  lacks this).

And maybe there are some more nand_bbt secrets...

Regards,
Shmulik

  reply	other threads:[~2012-06-28 18:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-28 15:47 [RFC] nand_btt : use nand chip->block_bad Matthieu CASTET
2012-06-28 18:31 ` Shmulik Ladkani [this message]
2012-06-29  8:41   ` Matthieu CASTET
2012-06-30 20:02     ` Shmulik Ladkani
2012-07-02  8:29       ` Matthieu CASTET
2012-07-24  3:53         ` Brian Norris
2012-07-25 11:02           ` Shmulik Ladkani
2012-08-06 22:21             ` Brian Norris
2012-08-07  7:09               ` Shmulik Ladkani
2012-09-18  1:06               ` Brian Norris
2012-09-18  1:28                 ` Scott Wood
2012-09-26 22:43                   ` Brian Norris
2012-09-26 22:57                     ` Scott Wood
2012-09-26 23:15                       ` 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=20120628213146.7d929204@halley \
    --to=shmulik.ladkani@gmail.com \
    --cc=computersforpeace@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=matthieu.castet@parrot.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.