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
next prev parent 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.