From: Stefan Agner <stefan@agner.ch>
To: Brian Norris <computersforpeace@gmail.com>
Cc: dwmw2@infradead.org, sebastian@breakpoint.cc, robh+dt@kernel.org,
pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
shawn.guo@linaro.org, kernel@pengutronix.de,
boris.brezillon@free-electrons.com, marb@ixxat.de,
aaron@tastycactus.com, bpringlemeir@gmail.com,
linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, albert.aribaud@3adev.fr,
Bill Pringlemeir <bpringlemeir@nbsps.com>
Subject: Re: [PATCH v9 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support
Date: Sat, 01 Aug 2015 01:35:52 +0200 [thread overview]
Message-ID: <9dd7975072cf16dd6ea1947bd4ae830a@agner.ch> (raw)
In-Reply-To: <20150731230901.GK10676@google.com>
Hi Brian,
On 2015-08-01 01:09, Brian Norris wrote:
<snip>
>> +static inline int vf610_nfc_correct_data(struct mtd_info *mtd, uint8_t *dat)
>> +{
>> + struct vf610_nfc *nfc = mtd_to_nfc(mtd);
>> + u8 ecc_status;
>> + u8 ecc_count;
>> + int flip;
>> +
>> + ecc_status = __raw_readb(nfc->regs + ECC_SRAM_ADDR * 8 + ECC_OFFSET);
>> + ecc_count = ecc_status & ECC_ERR_COUNT;
>> + if (!(ecc_status & ECC_STATUS_MASK))
>> + return ecc_count;
>> +
>> + /*
>> + * On an erased page, bit count should be zero or at least
>> + * less then half of the ECC strength
>> + */
>> + flip = count_written_bits(dat, nfc->chip.ecc.size, ecc_count);
>
> Sorry I didn't notice this earlier, but it appears you are falling into
> the same trap that almost everyone else is -- it is not sufficient to
> check just the page area; you also need to check the OOB. Suppose that
> a MTD user wrote mostly-0xff data to the page, then the page accumulates
> bitflips in the spare area and a few in the page area, such that
> eventually HW ECC can't correct them. If there are few enough zero bits
> in the data area, you will mistakenly think that this is a blank page
> below, and memset() it to 0xff. That would be disastrous!
>
> Fortunately, your code is otherwise quite well structured and looks
> good. A tip below.
>
>> +
>> + if (flip > ecc_count && flip > (nfc->chip.ecc.strength / 2))
>> + return -1;
>> +
>> + /* Erased page. */
>> + memset(dat, 0xff, nfc->chip.ecc.size);
>> + return 0;
>> +}
>> +
>> +static int vf610_nfc_read_page(struct mtd_info *mtd, struct nand_chip *chip,
>> + uint8_t *buf, int oob_required, int page)
>> +{
>> + int eccsize = chip->ecc.size;
>> + int stat;
>> +
>> + vf610_nfc_read_buf(mtd, buf, eccsize);
>> +
>> + if (oob_required)
>> + vf610_nfc_read_buf(mtd, chip->oob_poi, mtd->oobsize);
>
> To fix the bitflips issue above, you'll just want to unconditionally
> read the OOB (it's fine to ignore 'oob_required') and...
>
>> +
>> + stat = vf610_nfc_correct_data(mtd, buf);
>
> ...pass in chip->oob_poi as a third argument.
>
Hm, this probably will have an effect on performance, since we usually
omit the OOB if not requested. I could fetch the OOB from the NAND
controllers SRAM only if necessary (if HW ECC status is not ok...). Does
this sound reasonable?
>> +
>> + if (stat < 0)
>> + mtd->ecc_stats.failed++;
>> + else
>> + mtd->ecc_stats.corrected += stat;
>
> You've got another problem here: ecc.read_page() should be returning
> 'max_bitflips' here. So, since you have a single ECC region, this block
> should probably be:
>
> if (stat < 0) {
> mtd->ecc_stats.failed++;
> return 0;
> } else {
> mtd->ecc_stats.corrected += stat;
> return stat;
> }
>
Ok, will change that.
--
Stefan
next prev parent reply other threads:[~2015-07-31 23:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-31 16:52 [PATCH v9 0/5] mtd: nand: vf610_nfc: Freescale NFC for VF610 Stefan Agner
2015-07-31 16:52 ` [PATCH v9 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others Stefan Agner
2015-07-31 19:40 ` Albert ARIBAUD
2015-07-31 22:56 ` Brian Norris
2015-07-31 16:52 ` [PATCH v9 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support Stefan Agner
2015-07-31 23:09 ` Brian Norris
2015-07-31 23:35 ` Stefan Agner [this message]
2015-07-31 23:47 ` Brian Norris
2015-08-01 0:28 ` Stefan Agner
2015-08-01 1:50 ` Brian Norris
2015-07-31 16:52 ` [PATCH v9 3/5] mtd: nand: vf610_nfc: add device tree bindings Stefan Agner
2015-07-31 23:13 ` Stefan Agner
2015-07-31 23:17 ` Brian Norris
2015-07-31 16:53 ` [PATCH v9 4/5] ARM: dts: vf610twr: add NAND flash controller peripherial Stefan Agner
2015-07-31 16:53 ` [PATCH v9 5/5] ARM: dts: vf-colibri: enable NAND flash controller Stefan Agner
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=9dd7975072cf16dd6ea1947bd4ae830a@agner.ch \
--to=stefan@agner.ch \
--cc=aaron@tastycactus.com \
--cc=albert.aribaud@3adev.fr \
--cc=boris.brezillon@free-electrons.com \
--cc=bpringlemeir@gmail.com \
--cc=bpringlemeir@nbsps.com \
--cc=computersforpeace@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marb@ixxat.de \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=sebastian@breakpoint.cc \
--cc=shawn.guo@linaro.org \
/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
Powered by JetHome