From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Miquel Raynal <miquel.raynal@free-electrons.com>
Cc: Richard Weinberger <richard@nod.at>,
linux-mtd@lists.infradead.org,
Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>,
linux-kernel@vger.kernel.org, Marek Vasut <marek.vasut@gmail.com>,
Brian Norris <computersforpeace@gmail.com>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH v4] mtd: nand: Add OOB layout without ECC bytes
Date: Thu, 24 Aug 2017 21:52:22 +0200 [thread overview]
Message-ID: <20170824215222.1af8b752@bbrezillon> (raw)
In-Reply-To: <20170824083538.3009-1-miquel.raynal@free-electrons.com>
On Thu, 24 Aug 2017 10:35:38 +0200
Miquel Raynal <miquel.raynal@free-electrons.com> wrote:
> Add layout functions for large pages with mainly free bytes
> plus reserved space for Bad Block Markers. This may be useful for
> configurations that does set ECC_NONE. Specific chips that use
> on-die ECC feature, ie. the TOSHIBA BENAND (Built-in ECC NAND),
> might also take advantage of it: the ECC bytes are stored in an
> isolated area inaccessible by the driver and thus the OOB layout must
> only reserve space for bad block markers.
>
> Bad block markers position was extracted from the existing OOB layouts
> by assigning as free all the bytes marked as ECC.
>
> Normally, if NAND_ECC_NONE is chosen, the MTD user can use the whole OOB
> area (except the bytes reserved for the bad block markers) to store
> private data, but the NAND framework has been using the same OOB layout
> (the one reserving ECC bytes) no matter whether ECC is enabled or not.
> In order to not break existing MTD users which may rely on this layout
> to work properly, we keep things unchanged and only use the 'no_ecc'
> layouts for previously unsupported configurations.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---
> drivers/mtd/nand/nand_base.c | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index c5221795a1e8..ef40866d3435 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -109,6 +109,22 @@ const struct mtd_ooblayout_ops nand_ooblayout_sp_ops = {
> };
> EXPORT_SYMBOL_GPL(nand_ooblayout_sp_ops);
>
> +static int nand_ooblayout_free_lp_no_ecc(struct mtd_info *mtd, int section,
> + struct mtd_oob_region *oobregion)
> +{
> + if (section)
> + return -ERANGE;
> +
> + oobregion->offset = 2;
> + oobregion->length = mtd->oobsize - oobregion->offset;
> +
> + return 0;
> +}
> +
> +const struct mtd_ooblayout_ops nand_ooblayout_lp_no_ecc_ops = {
> + .free = nand_ooblayout_free_lp_no_ecc,
> +};
> +
> static int nand_ooblayout_ecc_lp(struct mtd_info *mtd, int section,
> struct mtd_oob_region *oobregion)
> {
> @@ -4649,6 +4665,19 @@ int nand_scan_tail(struct mtd_info *mtd)
> mtd_set_ooblayout(mtd, &nand_ooblayout_lp_hamming_ops);
> break;
> default:
> + /*
> + * Expose the whole OOB area to users if ECC_NONE
> + * is passed. We could do that for all kind of
> + * ->oobsize, but we must keep the old large/small
> + * page with ECC layout when ->oobsize <= 128 for
> + * compatibility reasons.
> + */
> + if (ecc->mode == NAND_ECC_NONE) {
> + mtd_set_ooblayout(mtd,
> + &nand_ooblayout_lp_no_ecc_ops);
Sorry again for not noticing that earlier but it seems
nand_ooblayout_lp_no_ecc_ops is not needed. Indeed, when ecc->bytes = 0
(which is the case when ecc->mode = NAND_ECC_NONE)
nand_ooblayout_lp_ops already exposes all OOB bytes as free. You can
just re-use nand_ooblayout_lp_ops here. The only thing you might want
to do is patch nand_ooblayout_ecc_lp() to return -ERANGE when
ecc->total is 0 so that the MTD user does not end up with a 0 length
OOB region.
prev parent reply other threads:[~2017-08-24 19:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-24 8:35 [PATCH v4] mtd: nand: Add OOB layout without ECC bytes Miquel Raynal
2017-08-24 19:52 ` 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=20170824215222.1af8b752@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=cyrille.pitchen@wedev4u.fr \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=miquel.raynal@free-electrons.com \
--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