All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Weijie Gao <weijie.gao@mediatek.com>
Cc: <u-boot@lists.denx.de>,
	 GSS_MTK_Uboot_upstream <GSS_MTK_Uboot_upstream@mediatek.com>,
	 Tom Rini <trini@konsulko.com>,
	Dario Binacchi <dario.binacchi@amarulasolutions.com>,
	 Michael Trimarchi <michael@amarulasolutions.com>,
	 Frieder Schrempf <frieder.schrempf@kontron.de>,
	 Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>,
	 Tianling Shen <cnsztl@gmail.com>,
	 Cheng Ming Lin <chengminglin@mxic.com.tw>,
	 Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Subject: Re: [PATCH] mtd: spinand: add support for Etron SPI-NAND flashes
Date: Wed, 27 May 2026 10:26:36 +0200	[thread overview]
Message-ID: <875x49l0lf.fsf@bootlin.com> (raw)
In-Reply-To: <20260429081313.151656-1-weijie.gao@mediatek.com> (Weijie Gao's message of "Wed, 29 Apr 2026 16:13:13 +0800")

Hello Weijie,

Sorry for the delay, I have a couple of comments, see below.

On 29/04/2026 at 16:13:13 +08, Weijie Gao <weijie.gao@mediatek.com> wrote:

> This patch adds some Etron SPI-NAND flashes from 1Gb to 8Gb with
> 4-bits/8-bits On-die ECC support.
>
> EM73C044VCF/EM73D044VCO/EM73E044VCE/EM73F044VCA are tested on MediaTek
> filogic MT7988 reference board.
>
> Datasheets:
> https://etron.com/wp-content/uploads/2024/08/EM73C044VCF-SPI-NAND-Flash_Rev-1.03.pdf
> https://etron.com/wp-content/uploads/2022/04/EM73D044VCOR-SPI-NAND-Flash_Rev-1.00.pdf
> https://etron.com/wp-content/uploads/2022/04/EM78DE044VC-SPI-NAND-Flash_Rev-1.01.pdf
> https://etron.com/wp-content/uploads/2024/08/EM73E044VCEG-SPI-NAND-Flash_Rev-1.00.pdf
> https://etron.com/wp-content/uploads/2022/04/EM738F044VCA-SPI-NAND-Flash_Rev-1.02.pdf

I haven't checked all the chips in detail, I checked just a couple of them.

> Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
> ---

[...]

> +#ifndef __UBOOT__
> +#include <linux/device.h>
> +#include <linux/kernel.h>
> +#endif

Please drop this #if block

> +#include <linux/mtd/spinand.h>
> +
> +#define SPINAND_MFR_ETRON		0xD5
> +
> +#define STATUS_ECC_LIMIT_BITFLIPS	(3 << 4)

Please add a prefix aligned with Etron's namespace.

> +static SPINAND_OP_VARIANTS(read_cache_variants,
> +		SPINAND_PAGE_READ_FROM_CACHE_1S_4S_4S_OP(0, 1, NULL, 0, 0),
> +		SPINAND_PAGE_READ_FROM_CACHE_1S_1S_4S_OP(0, 1, NULL, 0, 0),
> +		SPINAND_PAGE_READ_FROM_CACHE_1S_2S_2S_OP(0, 1, NULL, 0, 0),
> +		SPINAND_PAGE_READ_FROM_CACHE_1S_1S_2S_OP(0, 1, NULL, 0, 0),
> +		SPINAND_PAGE_READ_FROM_CACHE_FAST_1S_1S_1S_OP(0, 1, NULL, 0, 0),
> +		SPINAND_PAGE_READ_FROM_CACHE_1S_1S_1S_OP(0, 1, NULL, 0, 0));
> +
> +static SPINAND_OP_VARIANTS(write_cache_variants,
> +		SPINAND_PROG_LOAD_1S_1S_4S_OP(true, 0, NULL, 0),
> +		SPINAND_PROG_LOAD_1S_1S_1S_OP(true, 0, NULL, 0));
> +
> +static SPINAND_OP_VARIANTS(update_cache_variants,
> +		SPINAND_PROG_LOAD_1S_1S_4S_OP(false, 0, NULL, 0),
> +		SPINAND_PROG_LOAD_1S_1S_1S_OP(false, 0, NULL, 0));
> +
> +static int etron_ecc4_ooblayout_ecc(struct mtd_info *mtd, int section,
> +				    struct mtd_oob_region *region)
> +{
> +	struct spinand_device *spinand = mtd_to_spinand(mtd);
> +
> +	if (section >= spinand->base.memorg.pagesize / mtd->ecc_step_size)
> +		return -ERANGE;
> +
> +	region->offset = (8 * section) + 32;
> +	region->length = 8;

This should be grouped into one big continuous area.

> +
> +	return 0;
> +}
> +
> +static int etron_ecc4_ooblayout_free(struct mtd_info *mtd, int section,
> +				     struct mtd_oob_region *region)
> +{
> +	struct spinand_device *spinand = mtd_to_spinand(mtd);
> +
> +	if (section >= spinand->base.memorg.pagesize / mtd->ecc_step_size)
> +		return -ERANGE;
> +
> +	if (section) {
> +		region->offset = 8 * section;
> +		region->length = 8;

Ditto.

And same below, in the other OOB layouts.

> +	} else {
> +		/* section 0 has two bytes reserved for bad block mark */
> +		region->offset = 2;
> +		region->length = 6;
> +	}
> +
> +	return 0;
> +}
> +
> +static const struct mtd_ooblayout_ops etron_ecc4_ooblayout = {
> +	.ecc = etron_ecc4_ooblayout_ecc,
> +	.rfree = etron_ecc4_ooblayout_free,
> +};
> +
> +static int etron_ecc8_ooblayout_ecc(struct mtd_info *mtd, int section,
> +				    struct mtd_oob_region *region)
> +{
> +	struct spinand_device *spinand = mtd_to_spinand(mtd);
> +
> +	if (section >= spinand->base.memorg.pagesize / mtd->ecc_step_size)
> +		return -ERANGE;
> +
> +	region->offset = (14 * section) + 72;
> +	region->length = 14;
> +
> +	return 0;
> +}
> +
> +static int etron_ecc8_ooblayout_free(struct mtd_info *mtd, int section,
> +				     struct mtd_oob_region *region)
> +{
> +	struct spinand_device *spinand = mtd_to_spinand(mtd);
> +
> +	if (section >= spinand->base.memorg.pagesize / mtd->ecc_step_size)
> +		return -ERANGE;
> +
> +	if (section) {
> +		region->offset = 18 * section;
> +		region->length = 18;
> +	} else {
> +		/* section 0 has two bytes reserved for bad block mark */
> +		region->offset = 2;
> +		region->length = 16;
> +	}
> +
> +	return 0;
> +}
> +
> +static const struct mtd_ooblayout_ops etron_ecc8_ooblayout = {
> +	.ecc = etron_ecc8_ooblayout_ecc,
> +	.rfree = etron_ecc8_ooblayout_free,

         ^

Should not even compile?

> +};
> +
> +static int etron_ecc_get_status(struct spinand_device *spinand, u8 status)
> +{
> +	struct nand_device *nand = spinand_to_nand(spinand);
> +
> +	switch (status & STATUS_ECC_MASK) {
> +	case STATUS_ECC_NO_BITFLIPS:
> +		return 0;
> +
> +	case STATUS_ECC_UNCOR_ERROR:
> +		return -EBADMSG;
> +
> +	case STATUS_ECC_HAS_BITFLIPS:
> +		return nand->eccreq.strength >> 1;

This is incorrect, you should probably return strength - 1 if that is
what the bit means. We already had a discussion about this in the past:
https://lore.kernel.org/linux-mtd/20210908201624.237634-1-bert@biot.com/

> +
> +	case STATUS_ECC_LIMIT_BITFLIPS:
> +		return nand->eccreq.strength;
> +
> +	default:
> +		break;
> +	}
> +
> +	return -EINVAL;
> +}

Thanks,
Miquèl

  reply	other threads:[~2026-05-27 12:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-29  8:13 [PATCH] mtd: spinand: add support for Etron SPI-NAND flashes Weijie Gao
2026-05-27  8:26 ` Miquel Raynal [this message]
2026-05-27  8:46   ` Miquel Raynal
2026-06-09  8:37   ` Weijie Gao

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=875x49l0lf.fsf@bootlin.com \
    --to=miquel.raynal@bootlin.com \
    --cc=GSS_MTK_Uboot_upstream@mediatek.com \
    --cc=Takahiro.Kuwano@infineon.com \
    --cc=chengminglin@mxic.com.tw \
    --cc=cnsztl@gmail.com \
    --cc=dario.binacchi@amarulasolutions.com \
    --cc=frieder.schrempf@kontron.de \
    --cc=michael@amarulasolutions.com \
    --cc=mikhail.kshevetskiy@iopsys.eu \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=weijie.gao@mediatek.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.