linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Mike Dunn <mikedunn@newsguy.com>
To: Shmulik Ladkani <shmulik@jungo.com>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
	Ivan Djelic <ivan.djelic@parrot.com>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH] mtd: nand: Properly initialize 'mtd->bitflip_threshold' prior 'scan_bbt()' is invoked
Date: Sat, 09 Jun 2012 08:47:32 -0700	[thread overview]
Message-ID: <4FD37014.90109@newsguy.com> (raw)
In-Reply-To: <20120608182906.57b4844a@halley>

On 06/08/2012 08:29 AM, Shmulik Ladkani wrote:
> As of edbc454 [mtd: driver _read() returns max_bitflips; mtd_read()
> returns -EUCLEAN], 'mtd->bitflip_threshold' must be set for mtd devices
> having ECC, prior any 'mtd_read()' call.
> Otherwise, 'mtd_read()' will falsely return -EUCLEAN.
> 
> Normally, 'mtd->bitflip_threshold' is initialized when the MTD is added.
> 
> However, this is too late for NAND MTDs, as 'scan_bbt()' is invoked
> prior the existing initialization of 'mtd->bitflip_threshold'.
> 
> This is a problem since 'scan_bbt()' calls 'mtd_read()', in the case
> of a flash-based bad block table.
> It resulted in a falsely reported bitflips indication during BBT read,
> which lead to constant scrubbing of the flash BBT blocks.
> 
> Initialize 'mtd->bitflip_threshold' to its default value (if not already
> set by the driver), prior invocation of 'scan_bbt()'.
> 

Reviewed-by: Mike Dunn <mikedunn@newsguy.com>
(FWIW).

Thanks again Shmulik!

I do think that the patch to the bad block management code that I sent yesterday
should be merged as well.  That would also fix the problem, but it is really a
separate issue.  Currently ecc errors are ignored during the BBT creation for
some configurations but not for others (like that of the mxc_nand controller).
It looks like an oversight that they are not ignored, and it makes sense to
ignore them, since there's not much you can do about them at that time, and the
functions higher up the call stack don't try to.

Thanks,
Mike

  parent reply	other threads:[~2012-06-09 15:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-08 15:29 [PATCH] mtd: nand: Properly initialize 'mtd->bitflip_threshold' prior 'scan_bbt()' is invoked Shmulik Ladkani
2012-06-08 16:17 ` Shmulik Ladkani
2012-06-08 17:12 ` Artem Bityutskiy
2012-06-09  9:43 ` Sascha Hauer
2012-06-09 11:03   ` David Woodhouse
2012-06-09 15:47 ` Mike Dunn [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-06-08 15:41 Shmulik Ladkani

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=4FD37014.90109@newsguy.com \
    --to=mikedunn@newsguy.com \
    --cc=artem.bityutskiy@linux.intel.com \
    --cc=dwmw2@infradead.org \
    --cc=ivan.djelic@parrot.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=s.hauer@pengutronix.de \
    --cc=shmulik@jungo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).