From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Alexander Couzens <lynxis@fe80.eu>
Cc: linux-mtd@lists.infradead.org, Richard Weinberger <richard@nod.at>
Subject: Re: [PATCH] nand_base: fix regression on nand with 64/128 oob size
Date: Mon, 13 Mar 2017 07:46:41 +0100 [thread overview]
Message-ID: <20170313074641.28b383e7@bbrezillon> (raw)
In-Reply-To: <20170312200232.19269-1-lynxis@fe80.eu>
Hi Alexander,
On Sun, 12 Mar 2017 21:02:32 +0100
Alexander Couzens <lynxis@fe80.eu> wrote:
> 41b207a70d3a
When you refer to a commit, please put the commit description as well:
41b207a70d3a ("mtd: nand: implement the default mtd_ooblayout_ops")
> accidently changed the oob layout for nand when ECC doesn't use
> the full available ecc reserved data.
Oh crap! I didn't notice that when switching to the ooblayout approach.
> This only affects controllers which use the default large page ops
> nand_ooblayout_ecc_lp.
>
> E.g. for davinci:
> - nand has 2048 byte page, 64 byte oob
> - 3 byte ecc every 512 byte using 1bit hw ecc
> - requires 12 byte of oob space for ecc
> - old layout reserved 24 byte based on 64 byte oob
>
> Old layout started using byte from offset 40 while new layout
> uses the last X bytes so it fits into the end of oob.
> Meaning in this example the old layout uses byte 40-51, while
> the new layout use byte 52-63.
>
> Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Fixes + Cc-stable tags please.
> ---
> drivers/mtd/nand/nand_base.c | 19 ++++++++++++++++++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index b0524f8accb6..ba88345fd334 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -112,8 +112,25 @@ static int nand_ooblayout_ecc_lp(struct mtd_info *mtd, int section,
> if (section)
> return -ERANGE;
>
> + /* to be compatible with previous layouts
> + * 64 byte oob must have ecc data at byte 40,
> + * 128 byte oob must have ecc data at byte 80 */
> + switch (mtd->oobsize) {
> + case 64:
> + oobregion->offset = 40;
> + break;
> + case 128:
> + oobregion->offset = 80;
> + break;
> + default:
> + oobregion->offset = mtd->oobsize - oobregion->length;
> + break;
> + }
> +
> oobregion->length = ecc->total;
> - oobregion->offset = mtd->oobsize - oobregion->length;
> + if (oobregion->offset + oobregion->length > mtd->oobsize) {
> + return -ERANGE;
> + }
By doing that you break new users of the standard large page layout
which expect all ECC bytes to be placed at the end of the OOB region.
In all cases except the one you're fixing (Hamming in 1bit/512bytes) we
want the ECC start offset to be calculated based on the actual number
of ECC bytes, and not the max number of ECC bytes considering the
strongest case.
I'd recommend that you add a new layout for Hamming ECC in the 64 or 128
OOB bytes situation to fix the problem.
Thanks,
Boris
next prev parent reply other threads:[~2017-03-13 6:47 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-12 20:02 [PATCH] nand_base: fix regression on nand with 64/128 oob size Alexander Couzens
2017-03-13 6:46 ` Boris Brezillon [this message]
2017-05-02 8:13 ` [PATCH 0/3][v2] fixing 1bit hamming Alexander Couzens
2017-05-02 8:21 ` Boris Brezillon
2017-05-02 10:19 ` [PATCH][v3] mtd: nand: add ooblayout for old hamming layout Alexander Couzens
2017-05-02 12:03 ` Boris Brezillon
2017-05-03 1:57 ` Brian Norris
2017-05-02 8:13 ` [PATCH 1/3][v2] mtd/nand: " Alexander Couzens
2017-05-02 8:41 ` Boris Brezillon
2017-05-02 8:57 ` Boris Brezillon
2017-05-02 8:13 ` [PATCH 2/3][v2] nand_base: use nand_ooblayout_lp_hamming_ops for 1bit hamming as default Alexander Couzens
2017-05-02 8:49 ` Boris Brezillon
2017-05-02 8:13 ` [PATCH 3/3][v3] mtd: nand: davinci: set ECC algorithm explicitly for HW based ECC Alexander Couzens
2017-05-02 9:00 ` Boris Brezillon
2017-05-02 10:30 ` Boris Brezillon
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=20170313074641.28b383e7@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=linux-mtd@lists.infradead.org \
--cc=lynxis@fe80.eu \
--cc=richard@nod.at \
/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