All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace@gmail.com>
To: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Cc: linux-mtd@lists.infradead.org, Mike Dunn <mikedunn@newsguy.com>,
	dedekind1@gmail.com
Subject: Re: [PATCH] mtd: nand: ignore ecc errors during bbt reads
Date: Sun, 10 Jun 2012 23:53:25 -0700	[thread overview]
Message-ID: <4FD595E5.6070309@gmail.com> (raw)
In-Reply-To: <20120611094117.73145dda@pixies.home.jungo.com>

On 06/10/2012 11:41 PM, Shmulik Ladkani wrote:
> Thanks Brian for your comments,

You're welcome. And thanks for the interest in reviewing the code. Few 
people actually delve into nand_bbt.c, it seems :)

> On Sun, 10 Jun 2012 22:45:50 -0700 Brian Norris<computersforpeace@gmail.com>  wrote:
>>> Why not use 'MTD_OPS_RAW' in 'scan_block_fast()' as well (as done in
>>> 'scan_block_full')?
>>
>> Because when ECC is available on OOB, it is good to utilize it, so
>> that bitflips don't cause good blocks to be marked bad. Less
>> importantly, when bad block markers are written by Linux (with ECC),
>> then these markers can be read back more reliably.
>
> Ok (due to the second reason, as we're discussing the BBM read
> implementation).

I guess I worded my 'first' reason a little wrong. I meant: so that 
bitflips don't cause good blocks (0xff) to be read as bad blocks 
(bitflip => non-0xff). I think this would be far more significant, as a 
single bitflip in the BBM byte could cause errors.

>> So, I can send a patch that straightens out naming and brings
>> scan_block_fast() and scan_block_full() into alignment on using
>> MTD_OPS_PLACE_OOB. Then I think that we should continue using this
>> code in both:
>>                  /* Ignore ECC errors when checking for BBM */
>>                  if (ret&&  !mtd_is_bitflip_or_eccerr(ret))
>
> Sounds reasonable.

OK, I'll do that this week.

>> And we can (as agreed previously?) avoid using/checking max_bitflips
>> in mtd_read_oob(), although there is the datbuf+oob case that calls
>> nand_do_read_ops...
>
> This is a separate thing that needs to be addressed.
> See my findings in [1].

Right, I saw both threads kinda simultaneously. It looks like Mike may 
need to add some max_bitflips logic to mtd_read_oob after all.

Brian

  reply	other threads:[~2012-06-11  6:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-07 18:32 [PATCH] mtd: nand: ignore ecc errors during bbt reads Mike Dunn
2012-06-10 11:50 ` Shmulik Ladkani
2012-06-11  5:45   ` Brian Norris
2012-06-11  6:41     ` Shmulik Ladkani
2012-06-11  6:53       ` Brian Norris [this message]
2012-06-12 10:37     ` Artem Bityutskiy
2012-06-12 13:23     ` Mike Dunn

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=4FD595E5.6070309@gmail.com \
    --to=computersforpeace@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mikedunn@newsguy.com \
    --cc=shmulik.ladkani@gmail.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.