From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Andrea Scian <rnd4@dave-tech.it>
Cc: linux-mtd@lists.infradead.org,
David Woodhouse <dwmw2@infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
linux-kernel@vger.kernel.org, Han Xu <b45815@freescale.com>
Subject: Re: [RFC PATCH 2/2] mtd: nand: use nand_check_erased_ecc_chunk in default ECC read functions
Date: Fri, 31 Jul 2015 12:32:21 +0200 [thread overview]
Message-ID: <20150731123221.34cf601e@bbrezillon> (raw)
In-Reply-To: <55BB48D9.6050508@dave-tech.it>
Hi Andrea,
Adding Han in Cc.
On Fri, 31 Jul 2015 12:07:21 +0200
Andrea Scian <rnd4@dave-tech.it> wrote:
>
> Dear Boris,
>
>
> Il 30/07/2015 19:34, Boris Brezillon ha scritto:
> > The default NAND read functions are relying on an underlying controller
> > to correct bitflips, but some of those controller cannot properly fix
> > bitflips in erased pages.
> > In case of ECC failures, check if the page of subpage is empty before
> > reporting an ECC failure.
>
> I'm still wondering if chip->ecc.strength is the right threshold.
>
> Did you see my comments here [1]? WDYT?
Yes I've read it, and decided to go for ecc->strength as a first
step (I'm more interested in discussing the approach than the threshold
value right now ;-)).
Anyway, as you pointed out in the thread, writing data on an erased
page already containing some bitflips might generate even more
bitflips, so using a different threshold for the erased page check
makes sense. This threshold should definitely be correlated to the ECC
strength, but how, that's the question.
How about taking a rather conservative value like 10% of the specified
ECC strength, and see how it goes.
>
> Maybe we can have this discussion in a separate thread, if you want ;-)
No, I think we should keep discussing it in this thread.
Thanks,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2015-07-31 10:32 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-30 17:34 [RFC PATCH 0/2] mtd: nand: properly handle bitflips in erased pages Boris Brezillon
2015-07-30 17:34 ` [RFC PATCH 1/2] mtd: nand: add nand_check_erased helper functions Boris Brezillon
2015-07-31 7:10 ` Boris Brezillon
2015-07-31 10:06 ` Andrea Scian
2015-07-31 10:21 ` Boris Brezillon
2015-07-31 13:29 ` Andrea Scian
2015-07-31 13:58 ` Boris Brezillon
2015-08-04 15:42 ` Andrea Scian
2015-08-04 16:27 ` Boris Brezillon
2015-08-04 16:27 ` Boris Brezillon
2015-07-30 17:34 ` [RFC PATCH 2/2] mtd: nand: use nand_check_erased_ecc_chunk in default ECC read functions Boris Brezillon
2015-07-31 10:07 ` Andrea Scian
2015-07-31 10:32 ` Boris Brezillon [this message]
2015-07-31 13:40 ` Andrea Scian
2015-07-31 14:10 ` Boris Brezillon
2015-07-31 16:19 ` Andrea Scian
2015-07-31 16:27 ` Boris Brezillon
2015-08-03 11:16 ` Andrea Scian
2015-08-03 12:42 ` Boris Brezillon
2015-08-03 13:39 ` Andrea Scian
2015-08-03 19:32 ` Richard Weinberger
2015-08-04 7:02 ` Andrea Scian
2015-08-04 7:21 ` Richard Weinberger
2015-08-06 4:28 ` Andrea Scian
2015-08-06 9:19 ` Boris Brezillon
2015-08-06 9:42 ` Richard Weinberger
[not found] <mailman.4457.1438277726.1758.linux-mtd@lists.infradead.org>
[not found] <mailman.4514.1438332781.1758.linux-mtd@lists.infradead.org>
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=20150731123221.34cf601e@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=b45815@freescale.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=rnd4@dave-tech.it \
/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.