From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
linux-mtd@lists.infradead.org, Andrea Scian <rnd4@dave-tech.it>,
Richard Weinberger <richard@nod.at>,
linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [RESEND PATCH v3 5/5] mtd: nand: remove custom 'erased check' implementation
Date: Tue, 22 Sep 2015 10:08:37 +0200 [thread overview]
Message-ID: <20150922100837.0410c3f8@bbrezillon> (raw)
In-Reply-To: <20150921232832.GG31505@google.com>
Hi Brian,
On Mon, 21 Sep 2015 16:28:32 -0700
Brian Norris <computersforpeace@gmail.com> wrote:
> + others
>
> On Thu, Sep 03, 2015 at 06:03:42PM +0200, Boris Brezillon wrote:
> > Some drivers are manually checking for 'erased pages' while correcting
> > ECC bytes.
> > This logic is now done by the core infrastructure, and can thus be removed
> > from those drivers.
> >
> > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> > ---
> > drivers/mtd/nand/davinci_nand.c | 8 --------
> > drivers/mtd/nand/diskonchip.c | 32 ++------------------------------
> > drivers/mtd/nand/jz4740_nand.c | 18 ------------------
> > 3 files changed, 2 insertions(+), 56 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
> > index 816ef53..0d6adbe 100644
> > --- a/drivers/mtd/nand/davinci_nand.c
> > +++ b/drivers/mtd/nand/davinci_nand.c
> > @@ -316,14 +316,6 @@ static int nand_davinci_correct_4bit(struct mtd_info *mtd,
> > unsigned num_errors, corrected;
> > unsigned long timeo;
> >
> > - /* All bytes 0xff? It's an erased page; ignore its ECC. */
> > - for (i = 0; i < 10; i++) {
> > - if (ecc_code[i] != 0xff)
> > - goto compare;
> > - }
> > - return 0;
> > -
> > -compare:
> > /* Unpack ten bytes into eight 10 bit values. We know we're
> > * little-endian, and use type punning for less shifting/masking.
> > */
> > diff --git a/drivers/mtd/nand/diskonchip.c b/drivers/mtd/nand/diskonchip.c
> > index 7da266a..eb65769 100644
> > --- a/drivers/mtd/nand/diskonchip.c
> > +++ b/drivers/mtd/nand/diskonchip.c
> > @@ -936,37 +936,9 @@ static int doc200x_correct_data(struct mtd_info *mtd, u_char *dat,
> > calc_ecc[i] = ReadDOC_(docptr, DoC_Mplus_ECCSyndrome0 + i);
> > else
> > calc_ecc[i] = ReadDOC_(docptr, DoC_ECCSyndrome0 + i);
> > - if (calc_ecc[i] != empty_read_syndrome[i])
> > - emptymatch = 0;
> > }
> > - /* If emptymatch=1, the read syndrome is consistent with an
> > - all-0xff data and stored ecc block. Check the stored ecc. */
> > - if (emptymatch) {
> > - for (i = 0; i < 6; i++) {
> > - if (read_ecc[i] == 0xff)
> > - continue;
> > - emptymatch = 0;
> > - break;
> > - }
> > - }
> > - /* If emptymatch still =1, check the data block. */
> > - if (emptymatch) {
> > - /* Note: this somewhat expensive test should not be triggered
> > - often. It could be optimized away by examining the data in
> > - the readbuf routine, and remembering the result. */
> > - for (i = 0; i < 512; i++) {
> > - if (dat[i] == 0xff)
> > - continue;
> > - emptymatch = 0;
> > - break;
> > - }
> > - }
> > - /* If emptymatch still =1, this is almost certainly a freshly-
> > - erased block, in which case the ECC will not come out right.
> > - We'll suppress the error and tell the caller everything's
> > - OK. Because it is. */
> > - if (!emptymatch)
> > - ret = doc_ecc_decode(rs_decoder, dat, calc_ecc);
> > +
> > + ret = doc_ecc_decode(rs_decoder, dat, calc_ecc);
> > if (ret > 0)
> > printk(KERN_ERR "doc200x_correct_data corrected %d errors\n", ret);
> > }
>
> I see new warnings:
>
> drivers/mtd/nand/diskonchip.c: At top level:
> drivers/mtd/nand/diskonchip.c: In function ‘doc200x_correct_data’:
> drivers/mtd/nand/diskonchip.c:915:6: warning: unused variable ‘emptymatch’ [-Wunused-variable]
> int emptymatch = 1;
> ^
> drivers/mtd/nand/diskonchip.c:79:15: warning: ‘empty_read_syndrome’ defined but not used [-Wunused-variable]
> static u_char empty_read_syndrome[6] = { 0x26, 0xff, 0x6d, 0x47, 0x73, 0x7a };
> ^
Oops, I'll fix those warnings.
>
> I'd also like test results for these drivers before doing this. And I'm
> not sure how to find good testers for these drivers, even it users still
> exist.
Yep, the goal of this patch was to let people owning boards embedding
those chips test the changes.
If we don't get anyone to test it, maybe we should leave those drivers
unchanged at the expense of doing twice the test in case of bitflips in
erased pages or uncorrectable bitflips (which is really unlikely).
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
prev parent reply other threads:[~2015-09-22 8:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-03 16:03 [RESEND PATCH v3 0/5] mtd: nand: properly handle bitflips in erased pages Boris Brezillon
2015-09-03 16:03 ` [RESEND PATCH v3 1/5] mtd: nand: add nand_check_erased helper functions Boris Brezillon
2015-09-16 7:54 ` Boris Brezillon
2015-09-21 22:45 ` Brian Norris
2015-09-03 16:03 ` [RESEND PATCH v3 2/5] mtd: nand: return consistent error codes in ecc.correct() implementations Boris Brezillon
2015-09-21 23:10 ` Brian Norris
2015-09-22 7:54 ` Boris Brezillon
2015-09-03 16:03 ` [RESEND PATCH v3 3/5] mtd: nand: use nand_check_erased_ecc_chunk in default ECC read functions Boris Brezillon
2015-09-21 23:45 ` Brian Norris
2015-09-22 8:02 ` Boris Brezillon
2015-09-03 16:03 ` [RESEND PATCH v3 4/5] mtd: nand: make 'erased check' optional Boris Brezillon
2015-09-03 17:19 ` Boris Brezillon
2015-09-21 23:30 ` Brian Norris
2015-09-22 8:04 ` Boris Brezillon
2015-09-03 16:03 ` [RESEND PATCH v3 5/5] mtd: nand: remove custom 'erased check' implementation Boris Brezillon
2015-09-21 23:28 ` Brian Norris
2015-09-22 8:08 ` Boris Brezillon [this message]
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=20150922100837.0410c3f8@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-mtd@lists.infradead.org \
--cc=ralf@linux-mips.org \
--cc=richard@nod.at \
--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 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).