[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150731123221.34cf601e@bbrezillon>
Date: Fri, 31 Jul 2015 12:32:21 +0200
From: Boris Brezillon <boris.brezillon@...e-electrons.com>
To: Andrea Scian <rnd4@...e-tech.it>
Cc: linux-mtd@...ts.infradead.org,
David Woodhouse <dwmw2@...radead.org>,
Brian Norris <computersforpeace@...il.com>,
linux-kernel@...r.kernel.org, Han Xu <b45815@...escale.com>
Subject: Re: [RFC PATCH 2/2] mtd: nand: use nand_check_erased_ecc_chunk in
default ECC read functions
Hi Andrea,
Adding Han in Cc.
On Fri, 31 Jul 2015 12:07:21 +0200
Andrea Scian <rnd4@...e-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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists