Linux-mtd Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] mtd: slram: avoid dangling device list entries
From: Ruoyu Wang @ 2026-06-08 16:29 UTC (permalink / raw)
  To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra
  Cc: linux-mtd, linux-kernel

register_device() links a new slram_mtdlist entry before the entry is
fully initialized. If a later allocation, memremap(), or
mtd_device_register() fails, the failed entry can remain reachable from
the global list and later cleanup can dereference or free invalid state.

Build the new entry off-list, unwind partial initialization locally on
failure, and only publish the entry after mtd_device_register()
succeeds.

Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
---
 drivers/mtd/devices/slram.c | 95 ++++++++++++++++++++-----------------
 1 file changed, 51 insertions(+), 44 deletions(-)

diff --git a/drivers/mtd/devices/slram.c b/drivers/mtd/devices/slram.c
index 69cb63d99f573..c7f6beba078fe 100644
--- a/drivers/mtd/devices/slram.c
+++ b/drivers/mtd/devices/slram.c
@@ -129,71 +129,78 @@ static int slram_write(struct mtd_info *mtd, loff_t to, size_t len,
 static int register_device(char *name, unsigned long start, unsigned long length)
 {
 	slram_mtd_list_t **curmtd;
+	slram_mtd_list_t *new_mtd;
+	struct mtd_info *mtdinfo = NULL;
+	slram_priv_t *priv = NULL;
+	int ret = -ENOMEM;
 
 	curmtd = &slram_mtdlist;
 	while (*curmtd) {
 		curmtd = &(*curmtd)->next;
 	}
 
-	*curmtd = kmalloc_obj(slram_mtd_list_t);
-	if (!(*curmtd)) {
+	new_mtd = kmalloc_obj(slram_mtd_list_t);
+	if (!new_mtd) {
 		E("slram: Cannot allocate new MTD device.\n");
-		return(-ENOMEM);
+		return -ENOMEM;
 	}
-	(*curmtd)->mtdinfo = kzalloc_obj(struct mtd_info);
-	(*curmtd)->next = NULL;
+	new_mtd->next = NULL;
 
-	if ((*curmtd)->mtdinfo)	{
-		(*curmtd)->mtdinfo->priv =
-			kzalloc_obj(slram_priv_t);
-
-		if (!(*curmtd)->mtdinfo->priv) {
-			kfree((*curmtd)->mtdinfo);
-			(*curmtd)->mtdinfo = NULL;
-		}
+	mtdinfo = kzalloc_obj(struct mtd_info);
+	if (!mtdinfo) {
+		E("slram: Cannot allocate new MTD device.\n");
+		goto out_free;
 	}
+	new_mtd->mtdinfo = mtdinfo;
 
-	if (!(*curmtd)->mtdinfo) {
+	priv = kzalloc_obj(slram_priv_t);
+	if (!priv) {
 		E("slram: Cannot allocate new MTD device.\n");
-		return(-ENOMEM);
+		goto out_free;
 	}
+	mtdinfo->priv = priv;
 
-	if (!(((slram_priv_t *)(*curmtd)->mtdinfo->priv)->start =
-		memremap(start, length,
-			 MEMREMAP_WB | MEMREMAP_WT | MEMREMAP_WC))) {
+	priv->start = memremap(start, length,
+			       MEMREMAP_WB | MEMREMAP_WT | MEMREMAP_WC);
+	if (!priv->start) {
 		E("slram: memremap failed\n");
-		return -EIO;
+		ret = -EIO;
+		goto out_free;
 	}
-	((slram_priv_t *)(*curmtd)->mtdinfo->priv)->end =
-		((slram_priv_t *)(*curmtd)->mtdinfo->priv)->start + length;
-
-
-	(*curmtd)->mtdinfo->name = name;
-	(*curmtd)->mtdinfo->size = length;
-	(*curmtd)->mtdinfo->flags = MTD_CAP_RAM;
-	(*curmtd)->mtdinfo->_erase = slram_erase;
-	(*curmtd)->mtdinfo->_point = slram_point;
-	(*curmtd)->mtdinfo->_unpoint = slram_unpoint;
-	(*curmtd)->mtdinfo->_read = slram_read;
-	(*curmtd)->mtdinfo->_write = slram_write;
-	(*curmtd)->mtdinfo->owner = THIS_MODULE;
-	(*curmtd)->mtdinfo->type = MTD_RAM;
-	(*curmtd)->mtdinfo->erasesize = SLRAM_BLK_SZ;
-	(*curmtd)->mtdinfo->writesize = 1;
-
-	if (mtd_device_register((*curmtd)->mtdinfo, NULL, 0))	{
+	priv->end = priv->start + length;
+
+	mtdinfo->name = name;
+	mtdinfo->size = length;
+	mtdinfo->flags = MTD_CAP_RAM;
+	mtdinfo->_erase = slram_erase;
+	mtdinfo->_point = slram_point;
+	mtdinfo->_unpoint = slram_unpoint;
+	mtdinfo->_read = slram_read;
+	mtdinfo->_write = slram_write;
+	mtdinfo->owner = THIS_MODULE;
+	mtdinfo->type = MTD_RAM;
+	mtdinfo->erasesize = SLRAM_BLK_SZ;
+	mtdinfo->writesize = 1;
+
+	ret = mtd_device_register(mtdinfo, NULL, 0);
+	if (ret) {
 		E("slram: Failed to register new device\n");
-		memunmap(((slram_priv_t *)(*curmtd)->mtdinfo->priv)->start);
-		kfree((*curmtd)->mtdinfo->priv);
-		kfree((*curmtd)->mtdinfo);
-		return(-EAGAIN);
+		goto out_unmap;
 	}
+	*curmtd = new_mtd;
 	T("slram: Registered device %s from %luKiB to %luKiB\n", name,
 			(start / 1024), ((start + length) / 1024));
 	T("slram: Mapped from 0x%p to 0x%p\n",
-			((slram_priv_t *)(*curmtd)->mtdinfo->priv)->start,
-			((slram_priv_t *)(*curmtd)->mtdinfo->priv)->end);
-	return(0);
+			priv->start, priv->end);
+	return 0;
+
+out_unmap:
+	memunmap(priv->start);
+out_free:
+	kfree(priv);
+	kfree(mtdinfo);
+	kfree(new_mtd);
+	return ret;
 }
 
 static void unregister_devices(void)
-- 
2.51.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related

* [PATCH 0/4] mtd: rawnand: qcom: Add MDM9607
From: Stephan Gerhold @ 2026-06-08 13:20 UTC (permalink / raw)
  To: Manivannan Sadhasivam, Miquel Raynal
  Cc: Richard Weinberger, Vignesh Raghavendra, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, linux-mtd, linux-arm-msm,
	devicetree, linux-kernel

MDM9607 has QPIC v1.5 that supports the OP_PAGE_READ_ONFI_READ command, but
is missing the rest of the hardware changes in QPIC v2. There is also only
a single clock that can be controlled using the RPM firmware. Document and
add the new qcom,mdm9607-nand compatible for this setup.

Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
---
Stephan Gerhold (4):
      dt-bindings: mtd: qcom,nandc: Add MDM9607 QPIC NAND controller
      mtd: rawnand: qcom: Make "aon" clock optional
      mtd: rawnand: qcom: Make has_onfi_read_op separate from qpic_version2
      mtd: rawnand: qcom: Add MDM9607 compatible

 .../devicetree/bindings/mtd/qcom,nandc.yaml        | 24 +++++++++++++++++
 drivers/mtd/nand/raw/qcom_nandc.c                  | 30 ++++++++++++++++------
 include/linux/mtd/nand-qpic-common.h               |  2 ++
 3 files changed, 48 insertions(+), 8 deletions(-)
---
base-commit: 19ed11aee966d91beebdef9d32ce926474872f79
change-id: 20260608-qcom-nandc-mdm9607-f2196eeb6bc0

Best regards,
--  
Stephan Gerhold <stephan.gerhold@linaro.org>


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply

* [PATCH 4/4] mtd: rawnand: qcom: Add MDM9607 compatible
From: Stephan Gerhold @ 2026-06-08 13:20 UTC (permalink / raw)
  To: Manivannan Sadhasivam, Miquel Raynal
  Cc: Richard Weinberger, Vignesh Raghavendra, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, linux-mtd, linux-arm-msm,
	devicetree, linux-kernel
In-Reply-To: <20260608-qcom-nandc-mdm9607-v1-0-4639a0492274@linaro.org>

MDM9607 has QPIC v1.5 that supports the OP_PAGE_READ_ONFI_READ command, but
is missing the rest of the hardware changes in QPIC v2. Add the new
qcom,mdm9607-nand compatible and set it to use has_onfi_read_op without
also setting qpic_version2.

Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
---
 drivers/mtd/nand/raw/qcom_nandc.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c
index 9217e8de5512..d7642db2e2df 100644
--- a/drivers/mtd/nand/raw/qcom_nandc.c
+++ b/drivers/mtd/nand/raw/qcom_nandc.c
@@ -2381,6 +2381,15 @@ static const struct qcom_nandc_props ipq8074_nandc_props = {
 	.bam_offset = 0x30000,
 };
 
+static const struct qcom_nandc_props mdm9607_nandc_props = {
+	.ecc_modes = (ECC_BCH_4BIT | ECC_BCH_8BIT),
+	.supports_bam = true,
+	.nandc_part_of_qpic = true,
+	.has_onfi_read_op = true,
+	.dev_cmd_reg_start = 0x7000,
+	.bam_offset = 0x30000,
+};
+
 static const struct qcom_nandc_props sdx55_nandc_props = {
 	.ecc_modes = (ECC_BCH_4BIT | ECC_BCH_8BIT),
 	.supports_bam = true,
@@ -2412,6 +2421,10 @@ static const struct of_device_id qcom_nandc_of_match[] = {
 		.compatible = "qcom,ipq8074-nand",
 		.data = &ipq8074_nandc_props,
 	},
+	{
+		.compatible = "qcom,mdm9607-nand",
+		.data = &mdm9607_nandc_props,
+	},
 	{
 		.compatible = "qcom,sdx55-nand",
 		.data = &sdx55_nandc_props,

-- 
2.54.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related

* [PATCH 1/4] dt-bindings: mtd: qcom,nandc: Add MDM9607 QPIC NAND controller
From: Stephan Gerhold @ 2026-06-08 13:20 UTC (permalink / raw)
  To: Manivannan Sadhasivam, Miquel Raynal
  Cc: Richard Weinberger, Vignesh Raghavendra, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, linux-mtd, linux-arm-msm,
	devicetree, linux-kernel
In-Reply-To: <20260608-qcom-nandc-mdm9607-v1-0-4639a0492274@linaro.org>

Add the qcom,mdm9607-nand compatible for the QPIC NAND controller used
inside the MDM9607 SoC.

On MDM9607, there is only a single controllable clock for the NAND
controller (RPM_SMD_QPIC_CLK). The same situation also applies e.g. for
qcom,sdx55-nand, but the corresponding device tree (qcom-sdx55.dtsi) works
around that by assigning a dummy clock (&nand_clk_dummy) to the second
clock ("aon") that is required by the dt-bindings. This is not really
useful, so avoid doing that for new platforms by excluding the second "aon"
clock entry in the dt-bindings.

Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
---
 .../devicetree/bindings/mtd/qcom,nandc.yaml        | 24 ++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml b/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml
index 5511389960f0..4a9ba32cbddd 100644
--- a/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml
+++ b/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml
@@ -22,17 +22,20 @@ properties:
               - qcom,ipq4019-nand
               - qcom,ipq6018-nand
               - qcom,ipq8074-nand
+              - qcom,mdm9607-nand
               - qcom,sdx55-nand
 
   reg:
     maxItems: 1
 
   clocks:
+    minItems: 1
     items:
       - description: Core Clock
       - description: Always ON Clock
 
   clock-names:
+    minItems: 1
     items:
       - const: core
       - const: aon
@@ -101,6 +104,26 @@ allOf:
           items:
             - const: rxtx
 
+  # MDM9607 has no (separately controllable) "aon" clock, only "core"
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - qcom,mdm9607-nand
+    then:
+      properties:
+        clocks:
+          maxItems: 1
+        clock-names:
+          maxItems: 1
+    else:
+      properties:
+        clocks:
+          minItems: 2
+        clock-names:
+          minItems: 2
+
   - if:
       properties:
         compatible:
@@ -121,6 +144,7 @@ allOf:
               - qcom,ipq4019-nand
               - qcom,ipq6018-nand
               - qcom,ipq8074-nand
+              - qcom,mdm9607-nand
               - qcom,sdx55-nand
 
     then:

-- 
2.54.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related

* [PATCH 3/4] mtd: rawnand: qcom: Make has_onfi_read_op separate from qpic_version2
From: Stephan Gerhold @ 2026-06-08 13:20 UTC (permalink / raw)
  To: Manivannan Sadhasivam, Miquel Raynal
  Cc: Richard Weinberger, Vignesh Raghavendra, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, linux-mtd, linux-arm-msm,
	devicetree, linux-kernel
In-Reply-To: <20260608-qcom-nandc-mdm9607-v1-0-4639a0492274@linaro.org>

QPIC v1.5 requires using the OP_PAGE_READ_ONFI_READ command, but is missing
the rest of the hardware changes that are currently covered by the QPIC v2
(qpic_version2) check in the driver. Split that into an extra
has_onfi_read_op feature flag so it can be separately enabled.

No functional change.

Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
---
 drivers/mtd/nand/raw/qcom_nandc.c    | 15 ++++++++-------
 include/linux/mtd/nand-qpic-common.h |  2 ++
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c
index 0251dd591d40..9217e8de5512 100644
--- a/drivers/mtd/nand/raw/qcom_nandc.c
+++ b/drivers/mtd/nand/raw/qcom_nandc.c
@@ -1564,7 +1564,7 @@ static int qcom_op_cmd_mapping(struct nand_chip *chip, u8 opcode,
 		cmd = OP_FETCH_ID;
 		break;
 	case NAND_CMD_PARAM:
-		if (nandc->props->qpic_version2)
+		if (nandc->props->has_onfi_read_op)
 			cmd = OP_PAGE_READ_ONFI_READ;
 		else
 			cmd = OP_PAGE_READ;
@@ -1903,7 +1903,7 @@ static int qcom_param_page_type_exec(struct nand_chip *chip,  const struct nand_
 		nandc->regs->ecc_buf_cfg = cpu_to_le32(ECC_CFG_ECC_DISABLE);
 
 	/* configure CMD1 and VLD for ONFI param probing in QPIC v1 */
-	if (!nandc->props->qpic_version2) {
+	if (!nandc->props->has_onfi_read_op) {
 		nandc->regs->vld = cpu_to_le32((nandc->vld & ~READ_START_VLD));
 		nandc->regs->cmd1 = cpu_to_le32((nandc->cmd1 & ~READ_ADDR_MASK) |
 						FIELD_PREP(READ_ADDR_MASK, NAND_CMD_PARAM));
@@ -1911,7 +1911,7 @@ static int qcom_param_page_type_exec(struct nand_chip *chip,  const struct nand_
 
 	nandc->regs->exec = cpu_to_le32(1);
 
-	if (!nandc->props->qpic_version2) {
+	if (!nandc->props->has_onfi_read_op) {
 		nandc->regs->orig_cmd1 = cpu_to_le32(nandc->cmd1);
 		nandc->regs->orig_vld = cpu_to_le32(nandc->vld);
 	}
@@ -1925,7 +1925,7 @@ static int qcom_param_page_type_exec(struct nand_chip *chip,  const struct nand_
 	else
 		nandc_set_read_loc_first(chip, reg_base, 0, len, 1);
 
-	if (!nandc->props->qpic_version2) {
+	if (!nandc->props->has_onfi_read_op) {
 		qcom_write_reg_dma(nandc, &nandc->regs->vld, NAND_DEV_CMD_VLD, 1, 0);
 		qcom_write_reg_dma(nandc, &nandc->regs->cmd1, NAND_DEV_CMD1, 1, NAND_BAM_NEXT_SGL);
 	}
@@ -1939,7 +1939,7 @@ static int qcom_param_page_type_exec(struct nand_chip *chip,  const struct nand_
 			   nandc->buf_count, 0);
 
 	/* restore CMD1 and VLD regs */
-	if (!nandc->props->qpic_version2) {
+	if (!nandc->props->has_onfi_read_op) {
 		qcom_write_reg_dma(nandc, &nandc->regs->orig_cmd1, NAND_DEV_CMD1_RESTORE, 1, 0);
 		qcom_write_reg_dma(nandc, &nandc->regs->orig_vld, NAND_DEV_CMD_VLD_RESTORE, 1,
 				   NAND_BAM_NEXT_SGL);
@@ -2041,7 +2041,7 @@ static int qcom_nandc_setup(struct qcom_nand_controller *nandc)
 	if (!nandc->props->nandc_part_of_qpic)
 		nandc_write(nandc, SFLASHC_BURST_CFG, 0);
 
-	if (!nandc->props->qpic_version2)
+	if (!nandc->props->has_onfi_read_op)
 		nandc_write(nandc, dev_cmd_reg_addr(nandc, NAND_DEV_CMD_VLD),
 			    NAND_DEV_CMD_VLD_VAL);
 
@@ -2063,7 +2063,7 @@ static int qcom_nandc_setup(struct qcom_nand_controller *nandc)
 	}
 
 	/* save the original values of these registers */
-	if (!nandc->props->qpic_version2) {
+	if (!nandc->props->has_onfi_read_op) {
 		nandc->cmd1 = nandc_read(nandc, dev_cmd_reg_addr(nandc, NAND_DEV_CMD1));
 		nandc->vld = NAND_DEV_CMD_VLD_VAL;
 	}
@@ -2385,6 +2385,7 @@ static const struct qcom_nandc_props sdx55_nandc_props = {
 	.ecc_modes = (ECC_BCH_4BIT | ECC_BCH_8BIT),
 	.supports_bam = true,
 	.nandc_part_of_qpic = true,
+	.has_onfi_read_op = true,
 	.qpic_version2 = true,
 	.dev_cmd_reg_start = 0x7000,
 	.bam_offset = 0x30000,
diff --git a/include/linux/mtd/nand-qpic-common.h b/include/linux/mtd/nand-qpic-common.h
index 006ca8c978a9..437448995187 100644
--- a/include/linux/mtd/nand-qpic-common.h
+++ b/include/linux/mtd/nand-qpic-common.h
@@ -443,6 +443,7 @@ struct qcom_nand_controller {
  * @dev_cmd_reg_start - NAND_DEV_CMD_* registers starting offset
  * @supports_bam - whether NAND controller is using BAM
  * @nandc_part_of_qpic - whether NAND controller is part of qpic IP
+ * @has_onfi_read_op - whether ONFI param page read command is supported
  * @qpic_version2 - flag to indicate QPIC IP version 2
  * @use_codeword_fixup - whether NAND has different layout for boot partitions
  */
@@ -452,6 +453,7 @@ struct qcom_nandc_props {
 	u32 bam_offset;
 	bool supports_bam;
 	bool nandc_part_of_qpic;
+	bool has_onfi_read_op;
 	bool qpic_version2;
 	bool use_codeword_fixup;
 };

-- 
2.54.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related

* [PATCH 2/4] mtd: rawnand: qcom: Make "aon" clock optional
From: Stephan Gerhold @ 2026-06-08 13:20 UTC (permalink / raw)
  To: Manivannan Sadhasivam, Miquel Raynal
  Cc: Richard Weinberger, Vignesh Raghavendra, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, linux-mtd, linux-arm-msm,
	devicetree, linux-kernel
In-Reply-To: <20260608-qcom-nandc-mdm9607-v1-0-4639a0492274@linaro.org>

Some SoCs (e.g. MDM9607, SDX55) have only a single separately controllable
clock for the NAND controller. The actual clocks in the hardware are
managed by the firmware and turned on all together when needed. In this
case, there is no separate "aon" clock that can be described in the device
tree.

Make the second "aon" clock optional to avoid an error when it is missing.
For platforms that really need it, the dt-bindings are responsible for
validating that.

Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
---
 drivers/mtd/nand/raw/qcom_nandc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c
index 4b80ce084d9a..0251dd591d40 100644
--- a/drivers/mtd/nand/raw/qcom_nandc.c
+++ b/drivers/mtd/nand/raw/qcom_nandc.c
@@ -2280,7 +2280,7 @@ static int qcom_nandc_probe(struct platform_device *pdev)
 	if (IS_ERR(nandc->core_clk))
 		return PTR_ERR(nandc->core_clk);
 
-	nandc->aon_clk = devm_clk_get(dev, "aon");
+	nandc->aon_clk = devm_clk_get_optional(dev, "aon");
 	if (IS_ERR(nandc->aon_clk))
 		return PTR_ERR(nandc->aon_clk);
 

-- 
2.54.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related

* [PATCH next] drivers/mtd/parsers: Replace strcpy() into kmalloc()ed buffer
From: david.laight.linux @ 2026-06-08  9:55 UTC (permalink / raw)
  To: Kees Cook, linux-hardening, linux-kernel, linux-mtd
  Cc: Arnd Bergmann, Miquel Raynal, Richard Weinberger,
	Vignesh Raghavendra, David Laight

From: David Laight <david.laight.linux@gmail.com>

The length of nullname is known (and used for the kmalloc) so use
memcpy() instead of strcpy() to copy it into place.

Use strscpy() and the length it returns to copy over the names.

Signed-off-by: David Laight <david.laight.linux@gmail.com>
---
This is one of a group of patches that remove potentially unbounded
strcpy() calls.

They are mostly replaced by strscpy() or, when strlen() has just been
called, with memcpy() (usually including the '\0').

Calls with copy string literals into arrays are left unchanged.
They are safe and easily detected as such.

The changes were made by getting the compiler to detect the calls and
then fixing the code by hand.

Note that all the changes are only compile tested.

Some Makefiles were changed to allow files to contain strcpy().
As well as 'difficult to fix' files, this included 'show' functions
as they really need to use sysfs_emit() or seq_printf().

All the patches are being sent individually to avoid very long cc lists.
Apologies for the terse commit messages and likely unexpected tags.
(There are about 100 patches in total.)

 drivers/mtd/parsers/redboot.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/parsers/redboot.c b/drivers/mtd/parsers/redboot.c
index bf162c44eafe..e1e280b5fa40 100644
--- a/drivers/mtd/parsers/redboot.c
+++ b/drivers/mtd/parsers/redboot.c
@@ -249,7 +249,7 @@ static int parse_redboot_partitions(struct mtd_info *master,
 	nullname = (char *)&parts[nrparts];
 #ifdef CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED
 	if (nulllen > 0)
-		strcpy(nullname, nullstring);
+		memcpy(nullname, nullstring, nulllen);
 #endif
 	names = nullname + nulllen;
 
@@ -264,11 +264,13 @@ static int parse_redboot_partitions(struct mtd_info *master,
 	}
 #endif
 	for ( ; i < nrparts; i++) {
+		int len;
 		parts[i].size = fl->img->size;
 		parts[i].offset = fl->img->flash_base;
 		parts[i].name = names;
 
-		strcpy(names, fl->img->name);
+		len = strscpy(names, fl->img->name, namelen);
+		BUG_ON(len < 0);
 #ifdef CONFIG_MTD_REDBOOT_PARTS_READONLY
 		if (!strcmp(names, "RedBoot") ||
 		    !strcmp(names, "RedBoot config") ||
@@ -276,7 +278,8 @@ static int parse_redboot_partitions(struct mtd_info *master,
 			parts[i].mask_flags = MTD_WRITEABLE;
 		}
 #endif
-		names += strlen(names) + 1;
+		names += len + 1;
+		namelen -= len + 1;
 
 #ifdef CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED
 		if (fl->next && fl->img->flash_base + fl->img->size + master->erasesize <= fl->next->img->flash_base) {
-- 
2.39.5


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related

* [PATCH next] drivers/mtd/ubi/block: Replace strcpy() with strscpy()
From: david.laight.linux @ 2026-06-08  9:55 UTC (permalink / raw)
  To: Kees Cook, linux-hardening, linux-kernel, linux-mtd
  Cc: Arnd Bergmann, Miquel Raynal, Richard Weinberger,
	Vignesh Raghavendra, David Laight

From: David Laight <david.laight.linux@gmail.com>

Use the result of the strscpy() that copies the parameter block
to save an extra strnlen() call

Signed-off-by: David Laight <david.laight.linux@gmail.com>
---
This is one of a group of patches that remove potentially unbounded
strcpy() calls.

They are mostly replaced by strscpy() or, when strlen() has just been
called, with memcpy() (usually including the '\0').

Calls with copy string literals into arrays are left unchanged.
They are safe and easily detected as such.

The changes were made by getting the compiler to detect the calls and
then fixing the code by hand.

Note that all the changes are only compile tested.

Some Makefiles were changed to allow files to contain strcpy().
As well as 'difficult to fix' files, this included 'show' functions
as they really need to use sysfs_emit() or seq_printf().

All the patches are being sent individually to avoid very long cc lists.
Apologies for the terse commit messages and likely unexpected tags.
(There are about 100 patches in total.)

 drivers/mtd/ubi/block.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/ubi/block.c b/drivers/mtd/ubi/block.c
index 8880a783c3bc..be9655b4a9e9 100644
--- a/drivers/mtd/ubi/block.c
+++ b/drivers/mtd/ubi/block.c
@@ -96,7 +96,7 @@ static int __init ubiblock_set_param(const char *val,
 				     const struct kernel_param *kp)
 {
 	int i, ret;
-	size_t len;
+	ssize_t len;
 	struct ubiblock_param *param;
 	char buf[UBIBLOCK_PARAM_LEN];
 	char *pbuf = &buf[0];
@@ -105,20 +105,18 @@ static int __init ubiblock_set_param(const char *val,
 	if (!val)
 		return -EINVAL;
 
-	len = strnlen(val, UBIBLOCK_PARAM_LEN);
+	len = strscpy(buf, val);
 	if (len == 0) {
 		pr_warn("UBI: block: empty 'block=' parameter - ignored\n");
 		return 0;
 	}
 
-	if (len == UBIBLOCK_PARAM_LEN) {
+	if (len < 0) {
 		pr_err("UBI: block: parameter \"%s\" is too long, max. is %d\n",
 		       val, UBIBLOCK_PARAM_LEN);
 		return -EINVAL;
 	}
 
-	strcpy(buf, val);
-
 	/* Get rid of the final newline */
 	if (buf[len - 1] == '\n')
 		buf[len - 1] = '\0';
@@ -137,12 +135,12 @@ static int __init ubiblock_set_param(const char *val,
 		ret = kstrtoint(tokens[1], 10, &param->vol_id);
 		if (ret < 0) {
 			param->vol_id = -1;
-			strcpy(param->name, tokens[1]);
+			strscpy(param->name, tokens[1]);
 		}
 
 	} else {
 		/* One parameter: must be device path */
-		strcpy(param->name, tokens[0]);
+		strscpy(param->name, tokens[0]);
 		param->ubi_num = -1;
 		param->vol_id = -1;
 	}
-- 
2.39.5


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related

* [PATCH next] drivers/mtd/ubi/build: Use strscpy() to copy strings into arrays
From: david.laight.linux @ 2026-06-08  9:54 UTC (permalink / raw)
  To: Kees Cook, linux-hardening, linux-kernel, linux-mtd
  Cc: Arnd Bergmann, Miquel Raynal, Richard Weinberger,
	Vignesh Raghavendra, David Laight

From: David Laight <david.laight.linux@gmail.com>

Replacing strcpy() with strscpy() ensures that overflow of the target
buffer cannot happen.

Signed-off-by: David Laight <david.laight.linux@gmail.com>
---
This is one of a group of patches that remove potentially unbounded
strcpy() calls.

They are mostly replaced by strscpy() or, when strlen() has just been
called, with memcpy() (usually including the '\0').

Calls with copy string literals into arrays are left unchanged.
They are safe and easily detected as such.

The changes were made by getting the compiler to detect the calls and
then fixing the code by hand.

Note that all the changes are only compile tested.

Some Makefiles were changed to allow files to contain strcpy().
As well as 'difficult to fix' files, this included 'show' functions
as they really need to use sysfs_emit() or seq_printf().

All the patches are being sent individually to avoid very long cc lists.
Apologies for the terse commit messages and likely unexpected tags.
(There are about 100 patches in total.)

 drivers/mtd/ubi/build.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
index 674ad87809df..e7097d85035c 100644
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
@@ -1497,7 +1497,7 @@ static int ubi_mtd_param_parse(const char *val, const struct kernel_param *kp)
 		return 0;
 	}
 
-	strcpy(buf, val);
+	strscpy(buf, val);
 
 	/* Get rid of the final newline */
 	if (buf[len - 1] == '\n')
@@ -1512,7 +1512,7 @@ static int ubi_mtd_param_parse(const char *val, const struct kernel_param *kp)
 	}
 
 	p = &mtd_dev_param[mtd_devs];
-	strcpy(&p->name[0], tokens[0]);
+	strscpy(p->name, tokens[0]);
 
 	token = tokens[1];
 	if (token) {
-- 
2.39.5


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related

* Re: [PATCH v1] mtd: ubi: Fix rollback for explicit UBI device numbers
From: Zhihao Cheng @ 2026-06-08  4:45 UTC (permalink / raw)
  To: Yuho Choi, Richard Weinberger, Miquel Raynal
  Cc: linux-mtd, Vignesh Raghavendra, linux-kernel
In-Reply-To: <20260608040639.2616638-1-dbgh9129@gmail.com>

在 2026/6/8 12:06, Yuho Choi 写道:
> ubi_init_attach() rolls back module initialization failures by scanning
> ubi_devices[0..i-1], where i is the mtd= parameter index. That assumes
> the parameter index matches the UBI device number.
> 
> That assumption is not true when mtd= specifies an explicit ubi_num. A
> successfully attached device can be stored at a higher ubi_devices[]
> slot, and a later failure can miss it during rollback.
> 
> Scan the full ubi_devices[] array and detach by the actual array index,
> matching the way UBI devices are stored.
> 
> Fixes: 83ff59a06663 ("UBI: support ubi_num on mtd.ubi command line")
> Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
> ---
>   drivers/mtd/ubi/build.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
> diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
> index 674ad87809df..90c5c83d90e3 100644
> --- a/drivers/mtd/ubi/build.c
> +++ b/drivers/mtd/ubi/build.c
> @@ -1317,10 +1317,10 @@ static int __init ubi_init_attach(void)
>   	return 0;
>   
>   out_detach:
> -	for (k = 0; k < i; k++)
> +	for (k = 0; k < UBI_MAX_DEVICES; k++)
>   		if (ubi_devices[k]) {
>   			mutex_lock(&ubi_devices_mutex);
> -			ubi_detach_mtd_dev(ubi_devices[k]->ubi_num, 1);
> +			ubi_detach_mtd_dev(k, 1);
>   			mutex_unlock(&ubi_devices_mutex);
>   		}
>   	return err;
> 


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply

* [PATCH v1] mtd: ubi: Fix rollback for explicit UBI device numbers
From: Yuho Choi @ 2026-06-08  4:06 UTC (permalink / raw)
  To: Richard Weinberger, Miquel Raynal
  Cc: linux-mtd, Zhihao Cheng, Vignesh Raghavendra, linux-kernel,
	Yuho Choi

ubi_init_attach() rolls back module initialization failures by scanning
ubi_devices[0..i-1], where i is the mtd= parameter index. That assumes
the parameter index matches the UBI device number.

That assumption is not true when mtd= specifies an explicit ubi_num. A
successfully attached device can be stored at a higher ubi_devices[]
slot, and a later failure can miss it during rollback.

Scan the full ubi_devices[] array and detach by the actual array index,
matching the way UBI devices are stored.

Fixes: 83ff59a06663 ("UBI: support ubi_num on mtd.ubi command line")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
---
 drivers/mtd/ubi/build.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
index 674ad87809df..90c5c83d90e3 100644
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
@@ -1317,10 +1317,10 @@ static int __init ubi_init_attach(void)
 	return 0;
 
 out_detach:
-	for (k = 0; k < i; k++)
+	for (k = 0; k < UBI_MAX_DEVICES; k++)
 		if (ubi_devices[k]) {
 			mutex_lock(&ubi_devices_mutex);
-			ubi_detach_mtd_dev(ubi_devices[k]->ubi_num, 1);
+			ubi_detach_mtd_dev(k, 1);
 			mutex_unlock(&ubi_devices_mutex);
 		}
 	return err;
-- 
2.43.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related

* [PATCH next] drivers/mtd/devices/phram: Replace strnlen() strcpy() pair with strscpy()
From: david.laight.linux @ 2026-06-06 20:27 UTC (permalink / raw)
  To: Kees Cook, linux-hardening, Arnd Bergmann, linux-kernel,
	linux-mtd
  Cc: Joern Engel, Miquel Raynal, Richard Weinberger,
	Vignesh Raghavendra, David Laight

From: David Laight <david.laight.linux@gmail.com>

Use the result of strscpy() for the overflow check.

Signed-off-by: David Laight <david.laight.linux@gmail.com>
---
This is one of a group of patches that remove potentially unbounded
strcpy() calls.

They are mostly replaced by strscpy() or, when strlen() has just been
called, with memcpy() (usually including the '\0').

Calls with copy string literals into arrays are left unchanged.
They are safe and easily detected as such.

The changes were made by getting the compiler to detect the calls and
then fixing the code by hand.

Note that all the changes are only compile tested.

Some Makefiles were changed to allow files to contain strcpy().
As well as 'difficult to fix' files, this included 'show' functions
as they really need to use sysfs_emit() or seq_printf().

All the patches are being sent individually to avoid very long cc lists.
Apologies for the terse commit messages and likely unexpected tags.
(There are about 100 patches in total.)

 drivers/mtd/devices/phram.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mtd/devices/phram.c b/drivers/mtd/devices/phram.c
index b42cadcd76b1..7025d9bf5929 100644
--- a/drivers/mtd/devices/phram.c
+++ b/drivers/mtd/devices/phram.c
@@ -268,10 +268,8 @@ static int phram_setup(const char *val)
 	uint32_t rem;
 	int i, ret;
 
-	if (strnlen(val, sizeof(buf)) >= sizeof(buf))
+	if (strscpy(buf, val) < 0)
 		parse_err("parameter too long\n");
-
-	strcpy(str, val);
 	kill_final_newline(str);
 
 	for (i = 0; i < 4; i++)
-- 
2.39.5


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related

* [PATCH next] drivers/mtd/devices/block2mtd: Replace strnlen() strcpy() pair with strscpy()
From: david.laight.linux @ 2026-06-06 20:26 UTC (permalink / raw)
  To: Kees Cook, linux-hardening, Arnd Bergmann, linux-kernel,
	linux-mtd
  Cc: Joern Engel, Miquel Raynal, Richard Weinberger,
	Vignesh Raghavendra, David Laight

From: David Laight <david.laight.linux@gmail.com>

Use the result of strscpy() for the overflow check.

Signed-off-by: David Laight <david.laight.linux@gmail.com>
---
This is one of a group of patches that remove potentially unbounded
strcpy() calls.

They are mostly replaced by strscpy() or, when strlen() has just been
called, with memcpy() (usually including the '\0').

Calls with copy string literals into arrays are left unchanged.
They are safe and easily detected as such.

The changes were made by getting the compiler to detect the calls and
then fixing the code by hand.

Note that all the changes are only compile tested.

Some Makefiles were changed to allow files to contain strcpy().
As well as 'difficult to fix' files, this included 'show' functions
as they really need to use sysfs_emit() or seq_printf().

All the patches are being sent individually to avoid very long cc lists.
Apologies for the terse commit messages and likely unexpected tags.
(There are about 100 patches in total.)

 drivers/mtd/devices/block2mtd.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/mtd/devices/block2mtd.c b/drivers/mtd/devices/block2mtd.c
index 03e80b2c4f5a..466a061fa9bd 100644
--- a/drivers/mtd/devices/block2mtd.c
+++ b/drivers/mtd/devices/block2mtd.c
@@ -415,12 +415,11 @@ static int block2mtd_setup2(const char *val)
 	unsigned long timeout = MTD_DEFAULT_TIMEOUT;
 	int i, ret;
 
-	if (strnlen(val, sizeof(buf)) >= sizeof(buf)) {
+	if (strscpy(buf, val) < 0) {
 		pr_err("parameter too long\n");
 		return 0;
 	}
 
-	strcpy(str, val);
 	kill_final_newline(str);
 
 	for (i = 0; i < BLOCK2MTD_PARAM_MAX_COUNT; i++)
-- 
2.39.5


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related

* Re: [PATCH v3 01/13] spi: dt-bindings: allow spi-max-frequency to specify a frequency pair
From: Miquel Raynal @ 2026-06-05 16:55 UTC (permalink / raw)
  To: Conor Dooley
  Cc: Conor Dooley, Santhosh Kumar K, broonie, robh, krzk+dt, conor+dt,
	richard, vigneshr, pratyush, mwalle, takahiro.kuwano, linux-spi,
	devicetree, linux-kernel, linux-mtd, praneeth, u-kumar1, a-dutta
In-Reply-To: <20260605-cane-duct-a5c740fae417@spud>


>> > I am/was trying to come up with a scenario that would justify the patch
>> > man, stop trying to interpret it as what I want done.
>> 
>> Ah :-) Sorry the intention was unclear to me. So what is your preferred
>> take in the end?
>
> I think the generic dedicated property makes the most sense to me.

Ok, let's go for it then. Thanks for the feedback!

Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply

* Re: [PATCH v3 01/13] spi: dt-bindings: allow spi-max-frequency to specify a frequency pair
From: Conor Dooley @ 2026-06-05 15:20 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: Conor Dooley, Santhosh Kumar K, broonie, robh, krzk+dt, conor+dt,
	richard, vigneshr, pratyush, mwalle, takahiro.kuwano, linux-spi,
	devicetree, linux-kernel, linux-mtd, praneeth, u-kumar1, a-dutta
In-Reply-To: <87tsrh4fe2.fsf@bootlin.com>


[-- Attachment #1.1: Type: text/plain, Size: 3414 bytes --]

On Fri, Jun 05, 2026 at 09:26:13AM +0200, Miquel Raynal wrote:
> On 05/06/2026 at 08:17:18 +01, Conor Dooley <conor.dooley@microchip.com> wrote:
> 
> > On Fri, Jun 05, 2026 at 08:32:56AM +0200, Miquel Raynal wrote:
> >> On 04/06/2026 at 09:36:49 +01, Conor Dooley <conor@kernel.org> wrote:
> >> 
> >> > On Thu, Jun 04, 2026 at 09:14:16AM +0200, Miquel Raynal wrote:
> >> >> Hi Conor,
> >> >> 
> >> >> >> >> > Right, and this I guess is what scuppers letting the controller driver
> >> >> >> >> > sort the configuration out itself and leaving the property as-is.
> >> >> >> >> > It could be that the speed in spi-max-frequency is lower than the "base
> >> >> >> >> > speed" of the controller but because of board routing or device
> >> >> >> >> > capability that the tuned mode is still required, right?
> >> >> >> >> 
> >> >> >> >> I do not actually expect any tuned mode/frequency to be mandatory.
> >> >> >> >
> >> >> >> > I think you misunderstood my use of "required", I meant that the new
> >> >> >> > property/information was needed in the scenario I described, not that it
> >> >> >> > should be a required property in a binding.
> >> >> >> 
> >> >> >> Yes I misunderstood the term indeed. However I still fail to catch what
> >> >> >> you meant here, I'm sorry. Would you mind rephrasing?
> >> >> >
> >> >> > I was talking about a scenario where you want to use the tuned mode to
> >> >> > achieve the maximum rate because of the device and/or board configuration,
> >> >> > but the rate is below the point where the controller would need tuning.
> >> >> > Say the controller needs tuning above 8 Hz but the conditions require
> >> >> > tuning to achieve more than 5 Hz. In this example, if the device can do
> >> >> > 6 Hz, spi-max-frequency (in the current form) would be set to 6 Hz, and
> >> >> > the controller would not enable the tuned mode, leading to problems
> >> >> > because the inflection point determined from the controller compatible
> >> >> > of 8 Hz would not have been reached.
> >> >> 
> >> >> I don't think this is a real situation. If the "conditions", as you say
> >> >> (ie. PCB routing, mostly) require tuning above 5, then spi-max-frequency
> >> >> should be 5.
> >> >
> >> > Then tuning mode would never be used.
> >> 
> >> Well, this is exactly what we propose in this series, a way to indicate
> >> two maximum frequencies, one that just works (like before) and a higher
> >> frequency that is only reachable after an extra tuning procedure.
> >> 
> >> > Remember, this is a theoretical world
> >> > where spi-max-frequency would contain the tuned frequency and the
> >> > controller was using compatible-specific speed thresholds to determine
> >> > if tuning was required.
> >> 
> >> That is not what we are proposing. I don't think indicating the "after
> >> tuning" frequency in a property that has long been used for an always
> >> reachable frequency is wise. Hence either the use of an array (the
> >> second entry could contain a higher frequency) or a secondary
> >> spi-max-frequency-whatever property.
> >
> > I am/was trying to come up with a scenario that would justify the patch
> > man, stop trying to interpret it as what I want done.
> 
> Ah :-) Sorry the intention was unclear to me. So what is your preferred
> take in the end?

I think the generic dedicated property makes the most sense to me.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 144 bytes --]

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply

* Re: [RFC PATCH 3/3] mtd: spi-nor: rework flash parameter initialization
From: Tudor Ambarus @ 2026-06-05 13:17 UTC (permalink / raw)
  To: Michael Walle, Pratyush Yadav, Takahiro Kuwano, Miquel Raynal,
	Richard Weinberger, Vignesh Raghavendra
  Cc: linux-mtd, linux-kernel
In-Reply-To: <20260601125438.3481722-4-mwalle@kernel.org>



On 6/1/26 3:52 PM, Michael Walle wrote:
> Rework how the flash parameters are initialized. It used to make a
> difference whether a flash is in the in-kernel database, whether it
> supports multi I/O and so on. Recently, that makes more and more
> problems because flash IDs are reused among legacy flashes (w/o SFDP
> support) and newer flashes [1,2,3,4].
> 
> Simplify the whole parameter initialization, by starting with the
> parameters we have in the in-kernel database and the try to parse SFDP
> (and let it override any settings).

You need to specify here as well about the potential problem of issuing
an unsupported command (rdsfdp), although practice showed us it's okay.

I can't remember who raised first the potential of issuing unsupported
commands. Was it macronix, sst?
> 
> [1] https://lore.kernel.org/linux-mtd/CAAyq3SYX9UPwhC_Ume_S2yxhQwimRvB=Y6O_+FFqokhNmw7jQg@mail.gmail.com/
> [2] https://lore.kernel.org/linux-mtd/DGB4745HRCFI.1DRYTHXURWZJO@kernel.org/
> [3] https://lore.kernel.org/linux-mtd/DD10GE4EOCD7.CPTN7198QFUV@kernel.org/
> [4] https://lore.kernel.org/linux-mtd/DD6SI06QNEE4.2YCRTWJHEAAQM@kernel.org/
> 
> Signed-off-by: Michael Walle <mwalle@kernel.org>
> ---
>  drivers/mtd/spi-nor/core.c | 65 +++++++++++++-------------------------
>  drivers/mtd/spi-nor/core.h |  1 -
>  2 files changed, 22 insertions(+), 44 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index fbf8c2d9c6b5..67e0377b606f 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -2868,11 +2868,10 @@ static void spi_nor_manufacturer_init_params(struct spi_nor *nor)
>  
>  /**
>   * spi_nor_no_sfdp_init_params() - Initialize the flash's parameters and
> - * settings based on nor->info->sfdp_flags. This method should be called only by
> - * flashes that do not define SFDP tables. If the flash supports SFDP but the
> - * information is wrong and the settings from this function can not be retrieved
> - * by parsing SFDP, one should instead use the fixup hooks and update the wrong
> - * bits.
> + * settings based on nor->info->sfdp_flags.
> + * If the flash supports SFDP but the information is wrong and the settings from
> + * this function can not be retrieved by parsing SFDP, one should instead use
> + * the fixup hooks and update the wrong bits.
>   * @nor:	pointer to a 'struct spi_nor'.
>   */
>  static void spi_nor_no_sfdp_init_params(struct spi_nor *nor)
> @@ -3053,43 +3052,25 @@ static int spi_nor_late_init_params(struct spi_nor *nor)
>  }
>  
>  /**
> - * spi_nor_sfdp_init_params_deprecated() - Deprecated way of initializing flash
> - * parameters and settings based on JESD216 SFDP standard.
> + * spi_nor_try_parse_sfdp() - Tries to parse flash parameters based
> + * on JESD216 SFDP standard.
>   * @nor:	pointer to a 'struct spi_nor'.
>   *
>   * The method has a roll-back mechanism: in case the SFDP parsing fails, the
> - * legacy flash parameters and settings will be restored.
> + * flash parameters and settings will be restored.
>   */
> -static void spi_nor_sfdp_init_params_deprecated(struct spi_nor *nor)
> +static int spi_nor_try_parse_sfdp(struct spi_nor *nor)
>  {
>  	struct spi_nor_flash_parameter sfdp_params;
> +	int ret;
>  
>  	memcpy(&sfdp_params, nor->params, sizeof(sfdp_params));
>  
> -	if (spi_nor_parse_sfdp(nor))
> +	ret = spi_nor_parse_sfdp(nor);
> +	if (ret)
>  		memcpy(nor->params, &sfdp_params, sizeof(*nor->params));
> -}
> -
> -/**
> - * spi_nor_init_params_deprecated() - Deprecated way of initializing flash
> - * parameters and settings.
> - * @nor:	pointer to a 'struct spi_nor'.
> - *
> - * The method assumes that flash doesn't support SFDP so it initializes flash
> - * parameters in spi_nor_no_sfdp_init_params() which later on can be overwritten
> - * when parsing SFDP, if supported.
> - */
> -static void spi_nor_init_params_deprecated(struct spi_nor *nor)
> -{
> -	spi_nor_no_sfdp_init_params(nor);
>  
> -	spi_nor_manufacturer_init_params(nor);
> -
> -	if (nor->info->no_sfdp_flags & (SPI_NOR_DUAL_READ |
> -					SPI_NOR_QUAD_READ |
> -					SPI_NOR_OCTAL_READ |
> -					SPI_NOR_OCTAL_DTR_READ))
> -		spi_nor_sfdp_init_params_deprecated(nor);
> +	return ret;
>  }
>  
>  /**
> @@ -3152,7 +3133,8 @@ static void spi_nor_init_default_params(struct spi_nor *nor)
>   *
>   * 1/ Default flash parameters initialization. The initializations are done
>   *    based on nor->info data:
> - *		spi_nor_info_init_params()
> + *		spi_nor_init_default_params()
> + *		spi_nor_no_sfdp_init_params()
>   *
>   * which can be overwritten by:
>   * 2/ Manufacturer flash parameters initialization. The initializations are
> @@ -3163,7 +3145,7 @@ static void spi_nor_init_default_params(struct spi_nor *nor)
>   * which can be overwritten by:
>   * 3/ SFDP flash parameters initialization. JESD216 SFDP is a standard and
>   *    should be more accurate that the above.
> - *		spi_nor_parse_sfdp() or spi_nor_no_sfdp_init_params()
> + *		spi_nor_try_parse_sfdp()
>   *
>   *    Please note that there is a ->post_bfpt() fixup hook that can overwrite
>   *    the flash parameters and settings immediately after parsing the Basic
> @@ -3189,17 +3171,14 @@ static int spi_nor_init_params(struct spi_nor *nor)
>  		return -ENOMEM;
>  
>  	spi_nor_init_default_params(nor);
> +	spi_nor_no_sfdp_init_params(nor);
> +	spi_nor_manufacturer_init_params(nor);
>  
> -	if (spi_nor_needs_sfdp(nor)) {
> -		ret = spi_nor_parse_sfdp(nor);
> -		if (ret) {
> -			dev_err(nor->dev, "BFPT parsing failed. Please consider using SPI_NOR_SKIP_SFDP when declaring the flash\n");
> -			return ret;
> -		}
> -	} else if (nor->info->no_sfdp_flags & SPI_NOR_SKIP_SFDP) {
> -		spi_nor_no_sfdp_init_params(nor);
> -	} else {
> -		spi_nor_init_params_deprecated(nor);
> +	ret = spi_nor_try_parse_sfdp(nor);

I find it fine. I'm concerned about the inconsistent rollback
mechanism, but this is a preexisting problem.

Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>


> +	if (ret && spi_nor_needs_sfdp(nor)) {
> +		dev_err(nor->dev,
> +			"SFDP parsing failed. You need to manually declare the flash parameters.\n");
> +		return ret;
>  	}
>  
>  	ret = spi_nor_late_init_params(nor);
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index 2ebc5c3caca1..3d7c31bff5cb 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -548,7 +548,6 @@ struct flash_info {
>  #define SPI_NOR_HAS_CMP			BIT(10)
>  
>  	u8 no_sfdp_flags;
> -#define SPI_NOR_SKIP_SFDP		BIT(0)

sashiko says you need to grep this further and remove all instances.

>  #define SECT_4K				BIT(1)
>  #define SPI_NOR_DUAL_READ		BIT(3)
>  #define SPI_NOR_QUAD_READ		BIT(4)


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply

* Re: [RFC PATCH 2/3] mtd: spi-nor: don't clear the SNOR_F_4B_OPCODES flag on failure
From: Tudor Ambarus @ 2026-06-05 13:05 UTC (permalink / raw)
  To: Michael Walle, Pratyush Yadav, Takahiro Kuwano, Miquel Raynal,
	Richard Weinberger, Vignesh Raghavendra
  Cc: linux-mtd, linux-kernel
In-Reply-To: <20260601125438.3481722-3-mwalle@kernel.org>


Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply

* Re: [RFC PATCH 1/3] mtd: spi-nor: spansion: s25fl256s0: remove SKIP_SFDP flag
From: Tudor Ambarus @ 2026-06-05 13:05 UTC (permalink / raw)
  To: Michael Walle, Pratyush Yadav, Takahiro Kuwano, Miquel Raynal,
	Richard Weinberger, Vignesh Raghavendra
  Cc: linux-mtd, linux-kernel
In-Reply-To: <20260601125438.3481722-2-mwalle@kernel.org>


Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply

* [PATCH v3 2/2] mtd: spi-nor: macronix: Restore fallback parameters for MX25L12805D
From: Cheng Ming Lin @ 2026-06-05  8:48 UTC (permalink / raw)
  To: Pratyush Yadav, Michael Walle, Takahiro Kuwano, Miquel Raynal,
	Richard Weinberger, Vignesh Raghavendra
  Cc: linux-mtd, linux-kernel, alvinzhou, Cheng Ming Lin, stable
In-Reply-To: <20260605084837.1875896-1-linchengming884@gmail.com>

From: Cheng Ming Lin <chengminglin@mxic.com.tw>

In a previous effort to drop flash_info fields and rely on SFDP, the
static size and no_sfdp_flags were removed from the MX25L12805D entry
(JEDEC ID 0xc22018).

At that time, the legacy MX25L12805D was already EOL and unavailable
for physical testing. Verification was inadvertently performed using
the newer MX25L12833F, which shares the same JEDEC ID but supports
SFDP. As a result, the probe succeeded during testing, leading to
the mistaken removal of the fallback parameters.

Since the actual MX25L12805D lacks SFDP support entirely, it strictly
requires these static parameters.

Restore .size = SZ_16M and .no_sfdp_flags = SECT_4K to this entry
to fix the probe failure for the legacy part.

Fixes: 947c86e481a0 ("mtd: spi-nor: macronix: Drop the redundant flash info fields")
Cc: stable@vger.kernel.org
Signed-off-by: Cheng Ming Lin <chengminglin@mxic.com.tw>
---
 drivers/mtd/spi-nor/macronix.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c
index 1adb79832..d13ea93b0 100644
--- a/drivers/mtd/spi-nor/macronix.c
+++ b/drivers/mtd/spi-nor/macronix.c
@@ -155,7 +155,9 @@ static const struct flash_info macronix_nor_parts[] = {
 	}, {
 		/* MX25L12805D, MX25L12833F, MX25L12845G */
 		.id = SNOR_ID(0xc2, 0x20, 0x18),
+		.size = SZ_16M,
 		.flags = SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP,
+		.no_sfdp_flags = SECT_4K,
 		.fixups = &mx25l12805d_4pp3b_fixups,
 	}, {
 		/* MX25L25635E, MX25L25645G */
-- 
2.25.1


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related

* [PATCH v3 0/2] mtd: spi-nor: macronix: Add support for MX25L12833F and MX25L12845G
From: Cheng Ming Lin @ 2026-06-05  8:48 UTC (permalink / raw)
  To: Pratyush Yadav, Michael Walle, Takahiro Kuwano, Miquel Raynal,
	Richard Weinberger, Vignesh Raghavendra
  Cc: linux-mtd, linux-kernel, alvinzhou, Cheng Ming Lin

From: Cheng Ming Lin <chengminglin@mxic.com.tw>

This is v3 of the patch series adding support for Macronix MX25L12833F
and MX25L12845G, and restoring fallback parameters for MX25L12805D.

I would like to sincerely apologize for the build errors in v2 reported by
the kernel test robot. I had made further modifications and fixed the
issues during my local testing, but I accidentally submitted an older,
incorrect version of the patches.

In this v3, I have corrected the mistake and changed the fixup hook to use
`post_sfdp` instead of `post_bfpt`.

Changes in v3:
- Changed the fixup hook from `post_bfpt` to `post_sfdp` for MX25L12805D.
- Fixed the build error caused by the incompatible pointer type in v2.

Changes in v2:
- Patch 1: Changed the fixup hook from late_init to post_bfpt. Since
  the legacy MX25L12805D lacks SFDP, it will not execute post_bfpt.
  This safely isolates the newer MX25L12833F/45G (which support SFDP)
  and enables 4PP for them without breaking the legacy part.
- Patch 1: Added detailed comments inside the fixup function explaining
  the ID collision and the rationale behind the hook choice, as
  suggested by reviewers.
- Patch 2 (New): Added a separate patch to restore the missing .size
  and .no_sfdp_flags fallback parameters for the legacy MX25L12805D.
  This fixes a probe failure caused by a previous commit and includes
  the appropriate Fixes and Cc: stable tags.

Below are the test results after applying the patch provided by Michael:
- mx25l12833f
zynq> cat /sys/kernel/debug/spi-nor/spi0.0/capabilities 
Supported read modes by the flash
 1S-1S-1S
  opcode        0x03
  mode cycles   0
  dummy cycles  0
 1S-1S-2S
  opcode        0x3b
  mode cycles   0
  dummy cycles  8
 1S-2S-2S
  opcode        0xbb
  mode cycles   0
  dummy cycles  4
 1S-1S-4S
  opcode        0x6b
  mode cycles   0
  dummy cycles  8
 1S-4S-4S
  opcode        0xeb
  mode cycles   2
  dummy cycles  4
 4S-4S-4S
  opcode        0xeb
  mode cycles   2
  dummy cycles  4

Supported page program modes by the flash
 1S-1S-1S
  opcode        0x02
 1S-4S-4S
  opcode        0x38

zynq> cat /sys/kernel/debug/spi-nor/spi0.0/params 
name            (null)
id              c2 20 18 c2 20 18
size            16.0 MiB
write size      1
page size       256
address nbytes  3
flags           HAS_LOCK | HAS_4BIT_BP | SOFT_RESET

opcodes
 read           0xeb
  dummy cycles  6
 erase          0xd8
 program        0x38
 8D extension   none

protocols
 read           1S-4S-4S
 write          1S-4S-4S
 register       1S-1S-1S

erase commands
 20 (4.00 KiB) [1]
 52 (32.0 KiB) [2]
 d8 (64.0 KiB) [3]
 c7 (16.0 MiB)

sector map
 region (in hex)   | erase mask | overlaid
 ------------------+------------+----------
 00000000-00ffffff |     [   3] | no

zynq> dd if=/dev/urandom of=/tmp/spi_test bs=1M count=2
2+0 records in
2+0 records out
2097152 bytes (2.0MB) copied, 0.083756 seconds, 23.9MB/s

zynq> mtd_debug erase /dev/mtd0 0 2097152
Erased 2097152 bytes from address 0x00000000 in flash

zynq> mtd_debug read /dev/mtd0 0 2097152 /tmp/spi_read
Copied 2097152 bytes from address 0x00000000 in flash to /tmp/spi_read

zynq> hexdump /tmp/spi_read
0000000 ffff ffff ffff ffff ffff ffff ffff ffff
*
0200000

zynq> sha256sum /tmp/spi_read
4bda3a28f4ffe603c0ec1258c0034d65a1a0d35ab7bd523a834608adabf03cc5  /tmp/spi_read

zynq> mtd_debug write /dev/mtd0 0 2097152 /tmp/spi_test 
Copied 2097152 bytes from /tmp/spi_test to address 0x00000000 in flash

zynq> mtd_debug read /dev/mtd0 0 2097152 /tmp/spi_read
Copied 2097152 bytes from address 0x00000000 in flash to /tmp/spi_read

zynq> sha256sum /tmp/spi*
07bc3ccaac03ebf2b46c78f0be620bb22ce431ed39044d89af9e57481dcdea82  /tmp/spi_read
07bc3ccaac03ebf2b46c78f0be620bb22ce431ed39044d89af9e57481dcdea82  /tmp/spi_test

zynq> mtd_debug erase /dev/mtd0 0 2097152
Erased 2097152 bytes from address 0x00000000 in flash

zynq> mtd_debug read /dev/mtd0 0 2097152 /tmp/spi_read
Copied 2097152 bytes from address 0x00000000 in flash to /tmp/spi_read

zynq> sha256sum /tmp/spi*
4bda3a28f4ffe603c0ec1258c0034d65a1a0d35ab7bd523a834608adabf03cc5  /tmp/spi_read
07bc3ccaac03ebf2b46c78f0be620bb22ce431ed39044d89af9e57481dcdea82  /tmp/spi_test

zynq> mtd_debug info /dev/mtd0
mtd.type = MTD_NORFLASH
mtd.flags = MTD_CAP_NORFLASH
mtd.size = 16777216 (16M)
mtd.erasesize = 65536 (64K)
mtd.writesize = 1 
mtd.oobsize = 0 
regions = 0

-mx25l12845g
zynq> cat /sys/kernel/debug/spi-nor/spi0.0/capabilities 
Supported read modes by the flash
 1S-1S-1S
  opcode        0x03
  mode cycles   0
  dummy cycles  0
 1S-1S-2S
  opcode        0x3b
  mode cycles   0
  dummy cycles  8
 1S-2S-2S
  opcode        0xbb
  mode cycles   0
  dummy cycles  4
 1S-1S-4S
  opcode        0x6b
  mode cycles   0
  dummy cycles  8
 1S-4S-4S
  opcode        0xeb
  mode cycles   2
  dummy cycles  4
 4S-4S-4S
  opcode        0xeb
  mode cycles   2
  dummy cycles  4

Supported page program modes by the flash
 1S-1S-1S
  opcode        0x02
 1S-4S-4S
  opcode        0x38

zynq> cat /sys/kernel/debug/spi-nor/spi0.0/params 
name            (null)
id              c2 20 18 c2 20 18
size            16.0 MiB
write size      1
page size       256
address nbytes  3
flags           HAS_LOCK | HAS_4BIT_BP | SOFT_RESET

opcodes
 read           0xeb
  dummy cycles  6
 erase          0xd8
 program        0x38
 8D extension   none

protocols
 read           1S-4S-4S
 write          1S-4S-4S
 register       1S-1S-1S

erase commands
 20 (4.00 KiB) [1]
 52 (32.0 KiB) [2]
 d8 (64.0 KiB) [3]
 c7 (16.0 MiB)

sector map
 region (in hex)   | erase mask | overlaid
 ------------------+------------+----------
 00000000-00ffffff |     [   3] | no

zynq> dd if=/dev/urandom of=/tmp/spi_test bs=1M count=2
2+0 records in
2+0 records out
2097152 bytes (2.0MB) copied, 0.084527 seconds, 23.7MB/s

zynq> mtd_debug erase /dev/mtd0 0 2097152
Erased 2097152 bytes from address 0x00000000 in flash

zynq> mtd_debug read /dev/mtd0 0 2097152 /tmp/spi_read
Copied 2097152 bytes from address 0x00000000 in flash to /tmp/spi_read

zynq> hexdump /tmp/spi_read
0000000 ffff ffff ffff ffff ffff ffff ffff ffff
*
0200000

zynq> sha256sum /tmp/spi_read
4bda3a28f4ffe603c0ec1258c0034d65a1a0d35ab7bd523a834608adabf03cc5  /tmp/spi_read

zynq> mtd_debug write /dev/mtd0 0 2097152 /tmp/spi_test 
Copied 2097152 bytes from /tmp/spi_test to address 0x00000000 in flash

zynq> mtd_debug read /dev/mtd0 0 2097152 /tmp/spi_read
Copied 2097152 bytes from address 0x00000000 in flash to /tmp/spi_read

zynq> sha256sum /tmp/spi*
926c0e33670888d2c0d9d602a502ccc0aacb52afe58b9d430ebcb88137a8e3bf  /tmp/spi_read
926c0e33670888d2c0d9d602a502ccc0aacb52afe58b9d430ebcb88137a8e3bf  /tmp/spi_test

zynq> mtd_debug erase /dev/mtd0 0 2097152
Erased 2097152 bytes from address 0x00000000 in flash

zynq> mtd_debug read /dev/mtd0 0 2097152 /tmp/spi_read
Copied 2097152 bytes from address 0x00000000 in flash to /tmp/spi_read

zynq> sha256sum /tmp/spi*
4bda3a28f4ffe603c0ec1258c0034d65a1a0d35ab7bd523a834608adabf03cc5  /tmp/spi_read
926c0e33670888d2c0d9d602a502ccc0aacb52afe58b9d430ebcb88137a8e3bf  /tmp/spi_test

zynq> mtd_debug info /dev/mtd0
mtd.type = MTD_NORFLASH
mtd.flags = MTD_CAP_NORFLASH
mtd.size = 16777216 (16M)
mtd.erasesize = 65536 (64K)
mtd.writesize = 1 
mtd.oobsize = 0 
regions = 0

Cheng Ming Lin (2):
  mtd: spi-nor: Add support for MX25L12833F and MX25L12845G
  mtd: spi-nor: macronix: Restore fallback parameters for MX25L12805D

 drivers/mtd/spi-nor/macronix.c | 28 +++++++++++++++++++++++++++-
 1 file changed, 27 insertions(+), 1 deletion(-)

-- 
2.25.1


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply

* [PATCH v3 1/2] mtd: spi-nor: Add support for MX25L12833F and MX25L12845G
From: Cheng Ming Lin @ 2026-06-05  8:48 UTC (permalink / raw)
  To: Pratyush Yadav, Michael Walle, Takahiro Kuwano, Miquel Raynal,
	Richard Weinberger, Vignesh Raghavendra
  Cc: linux-mtd, linux-kernel, alvinzhou, Cheng Ming Lin
In-Reply-To: <20260605084837.1875896-1-linchengming884@gmail.com>

From: Cheng Ming Lin <chengminglin@mxic.com.tw>

Add support for Macronix MX25L12833F and MX25L12845G SPI NOR flashes.
These parts share the same JEDEC ID (0xc2, 0x20, 0x18) as the legacy
MX25L12805D.

The newer flashes support SFDP and 1-4-4 Page Program in 3-byte address
mode, but this 4PP capability is not defined in their SFDP tables.
Conversely, the legacy MX25L12805D lacks SFDP support entirely and does
not support 4PP.

To safely enable 4PP for the newer flashes without breaking the legacy
part, introduce a post_sfdp fixup. Since the legacy MX25L12805D does
not support SFDP, it falls back to static parameters and will never
execute the post_sfdp hook. The newer flashes will successfully parse
the SFDP, trigger the hook, and safely append the SNOR_HWCAPS_PP_1_4_4
capability.

Signed-off-by: Cheng Ming Lin <chengminglin@mxic.com.tw>
---
 drivers/mtd/spi-nor/macronix.c | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c
index e97f5cbd9..1adb79832 100644
--- a/drivers/mtd/spi-nor/macronix.c
+++ b/drivers/mtd/spi-nor/macronix.c
@@ -83,6 +83,25 @@ mx25l3255e_late_init_fixups(struct spi_nor *nor)
 	return 0;
 }
 
+static int
+mx25l12805d_4pp3b_post_sfdp_fixups(struct spi_nor *nor)
+{
+	struct spi_nor_flash_parameter *params = nor->params;
+
+	/*
+	 * JEDEC ID 0xc22018 is shared by MX25L12805D (no SFDP, no 4PP) and
+	 * MX25L12833F/MX25L12845G (support SFDP and 4PP in 3-byte mode).
+	 * The legacy 05D lacks SFDP and will not execute this hook. For
+	 * the newer flashes, 3-byte 1-4-4 PP is not defined in SFDP, so
+	 * we safely enable it here.
+	 */
+	params->hwcaps.mask |= SNOR_HWCAPS_PP_1_4_4;
+	spi_nor_set_pp_settings(&params->page_programs[SNOR_CMD_PP_1_4_4],
+				SPINOR_OP_PP_1_4_4, SNOR_PROTO_1_4_4);
+
+	return 0;
+}
+
 static const struct spi_nor_fixups mx25l25635_fixups = {
 	.post_bfpt = mx25l25635_post_bfpt_fixups,
 	.post_sfdp = macronix_qpp4b_post_sfdp_fixups,
@@ -96,6 +115,10 @@ static const struct spi_nor_fixups mx25l3255e_fixups = {
 	.late_init = mx25l3255e_late_init_fixups,
 };
 
+static const struct spi_nor_fixups mx25l12805d_4pp3b_fixups = {
+	.post_sfdp = mx25l12805d_4pp3b_post_sfdp_fixups,
+};
+
 static const struct flash_info macronix_nor_parts[] = {
 	{
 		.id = SNOR_ID(0xc2, 0x20, 0x10),
@@ -130,9 +153,10 @@ static const struct flash_info macronix_nor_parts[] = {
 		.size = SZ_8M,
 		.no_sfdp_flags = SECT_4K,
 	}, {
-		/* MX25L12805D */
+		/* MX25L12805D, MX25L12833F, MX25L12845G */
 		.id = SNOR_ID(0xc2, 0x20, 0x18),
 		.flags = SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP,
+		.fixups = &mx25l12805d_4pp3b_fixups,
 	}, {
 		/* MX25L25635E, MX25L25645G */
 		.id = SNOR_ID(0xc2, 0x20, 0x19),
-- 
2.25.1


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related

* RE: [RFC PATCH 0/3] mtd: spi-nor: Rework flash parameter initialization
From: Takahiro.Kuwano @ 2026-06-05  8:50 UTC (permalink / raw)
  To: miquel.raynal, mwalle
  Cc: pratyush, richard, vigneshr, tudor.ambarus, linux-mtd,
	linux-kernel
In-Reply-To: <c8f082b6deb4483b9a6a5f54ac549d62@infineon.com>

> Hi,
> 
> > Hi Michael,
> >
> > On 01/06/2026 at 14:52:42 +02, Michael Walle <mwalle@kernel.org> wrote:
> >
> > > Try to simplify the flash initialization and get rid of the legacy
> > > handling. As default, all the flags of the in-kernel database are
> > > taken and amended with the SFDP data.
> > >
> > > This might have the consequence that all the flashes now get a
> > > RDSFPD opcode which might be an unknown opcode. But that was already
> > > the case for any flashes which were unknown to the linux kernel. So
> > > far, there was not a single complaint.
> > >
> > > See patch 3 for more information. If feedback is positive, this is
> > > intended to be applied to the spi-nor tree after the next merge
> > > window, so it will sit around in -next for quite some time and get
> > > some testing.
> > >
> > > That being said, I've just did a quick test on my boards. Please
> > > give it a test on your boards.
> >
> > Interesting cleanup, thanks for pushing it. I'll run some tests with
> > some old and newer SFDP based flashes. I do not have chips without SFDP
> > though.
> >
> I do have some non-SFDP chips (S25FL-S). Will get back to you with test
> result.

With my AMD Zynq-7000 & Infineon internal SPI controller, s25fl128s0,
s25fl128s1, and s25fl256s0 work fine.

Here is the test log of s25fl256s0:

zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/partname
s25fl256s0

zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/jedec_id
0102194d0080

zynq> cat /sys/bus/spi/devices/spi0.0/spi-nor/manufacturer
spansion

zynq> xxd -p /sys/bus/spi/devices/spi0.0/spi-nor/sfdp
xxd: /sys/bus/spi/devices/spi0.0/spi-nor/sfdp: No such file or directory
xxd: /sys/bus/spi/devices/spi0.0/spi-nor/sfdp: Bad file descriptor

zynq> md5sum /sys/bus/spi/devices/spi0.0/spi-nor/sfdp
md5sum: can't open '/sys/bus/spi/devices/spi0.0/spi-nor/sfdp': No such file or directory

zynq> test_spi.sh
2+0 records in
2+0 records out
2097152 bytes (2.0MB) copied, 0.074296 seconds, 26.9MB/s
Erased 2097152 bytes from address 0x00000000 in flash
Copied 2097152 bytes from address 0x00000000 in flash to spi_read
0000000 ffff ffff ffff ffff ffff ffff ffff ffff
*
0200000
4bda3a28f4ffe603c0ec1258c0034d65a1a0d35ab7bd523a834608adabf03cc5  spi_read
Copied 2097152 bytes from spi_test to address 0x00000000 in flash
Copied 2097152 bytes from address 0x00000000 in flash to spi_read
1565a9e729e432053d204d569952d5ee6d669e0ace84a88d681b20e4600df356  spi_read
1565a9e729e432053d204d569952d5ee6d669e0ace84a88d681b20e4600df356  spi_test
Erased 2097152 bytes from address 0x00000000 in flash
Copied 2097152 bytes from address 0x00000000 in flash to spi_read
4bda3a28f4ffe603c0ec1258c0034d65a1a0d35ab7bd523a834608adabf03cc5  spi_read
1565a9e729e432053d204d569952d5ee6d669e0ace84a88d681b20e4600df356  spi_test

zynq> cat /sys/kernel/debug/spi-nor/spi0.0/params
name            s25fl256s0
id              01 02 19 4d 00 80
size            32.0 MiB
write size      1
page size       256
address nbytes  4
flags           4B_OPCODES | HAS_16BIT_SR

opcodes
 read           0x6c
  dummy cycles  8
 erase          0xdc
 program        0x12
 8D extension   none

protocols
 read           1S-1S-4S
 write          1S-1S-1S
 register       1S-1S-1S

erase commands
 d8 (256 KiB) [0]
 c7 (32.0 MiB)

sector map
 region (in hex)   | erase mask | overlaid
 ------------------+------------+----------
 00000000-01ffffff |     [0   ] | no

zynq> cat /sys/kernel/debug/spi-nor/spi0.0/capabilities
Supported read modes by the flash
 1S-1S-1S
  opcode        0x03
  mode cycles   0
  dummy cycles  0
 1S-1S-1S (fast read)
  opcode        0x0b
  mode cycles   0
  dummy cycles  8
 1S-1S-2S
  opcode        0x3b
  mode cycles   0
  dummy cycles  8
 1S-1S-4S
  opcode        0x6b
  mode cycles   0
  dummy cycles  8

Supported page program modes by the flash
 1S-1S-1S
  opcode        0x02


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply

* RE: [RFC PATCH 2/3] mtd: spi-nor: don't clear the SNOR_F_4B_OPCODES flag on failure
From: Takahiro.Kuwano @ 2026-06-05  8:15 UTC (permalink / raw)
  To: mwalle, pratyush, miquel.raynal, richard, vigneshr, tudor.ambarus
  Cc: linux-mtd, linux-kernel
In-Reply-To: <20260601125438.3481722-3-mwalle@kernel.org>

> 
> This was introduced in commit 548ed6847f530 ("mtd: spi-nor: Add the
> SNOR_F_4B_OPCODES flag"). It looks like it was the rollback mechanism if
> parsing the SFDP failed, but was setting that flag first. Nowadays, that
> flag can only be set if spi_nor_parse_4bait() was successful. IOW, the
> flags won't be left in an undefined state if parsing SFDP fails.
> 
> Remove the unneeded code to be able to rework spi_nor_init_params().
> 
> Signed-off-by: Michael Walle <mwalle@kernel.org>

Reviewed-by: Takahiro Kuwano <takahiro.kuwano@infineon.com>


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply

* Re: [PATCH v2 2/2] mtd: spi-nor: macronix: Restore fallback parameters for MX25L12805D
From: kernel test robot @ 2026-06-05  8:07 UTC (permalink / raw)
  To: Cheng Ming Lin, Pratyush Yadav, Michael Walle, Takahiro Kuwano,
	Miquel Raynal, Richard Weinberger, Vignesh Raghavendra
  Cc: oe-kbuild-all, linux-mtd, linux-kernel, alvinzhou, Cheng Ming Lin,
	stable
In-Reply-To: <20260605005720.1857413-3-linchengming884@gmail.com>

Hi Cheng,

kernel test robot noticed the following build errors:

[auto build test ERROR on mtd/spi-nor/next]
[also build test ERROR on linus/master v7.1-rc6 next-20260604]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Cheng-Ming-Lin/mtd-spi-nor-Add-support-for-MX25L12833F-and-MX25L12845G/20260605-090612
base:   https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-nor/next
patch link:    https://lore.kernel.org/r/20260605005720.1857413-3-linchengming884%40gmail.com
patch subject: [PATCH v2 2/2] mtd: spi-nor: macronix: Restore fallback parameters for MX25L12805D
config: x86_64-rhel-9.4-func (https://download.01.org/0day-ci/archive/20260605/202606051000.gRYPMoXy-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260605/202606051000.gRYPMoXy-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606051000.gRYPMoXy-lkp@intel.com/

All errors (new ones prefixed by >>):

>> drivers/mtd/spi-nor/macronix.c:119:22: error: initialization of 'int (*)(struct spi_nor *, const struct sfdp_parameter_header *, const struct sfdp_bfpt *)' from incompatible pointer type 'int (*)(struct spi_nor *)' [-Wincompatible-pointer-types]
     119 |         .post_bfpt = mx25l12805d_4pp3b_post_bfpt_fixups,
         |                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/mtd/spi-nor/macronix.c:119:22: note: (near initialization for 'mx25l12805d_4pp3b_fixups.post_bfpt')


vim +119 drivers/mtd/spi-nor/macronix.c

   117	
   118	static const struct spi_nor_fixups mx25l12805d_4pp3b_fixups = {
 > 119		.post_bfpt = mx25l12805d_4pp3b_post_bfpt_fixups,
   120	};
   121	

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply

* RE: [RFC PATCH 1/3] mtd: spi-nor: spansion: s25fl256s0: remove SKIP_SFDP flag
From: Takahiro.Kuwano @ 2026-06-05  8:05 UTC (permalink / raw)
  To: mwalle, pratyush, miquel.raynal, richard, vigneshr, tudor.ambarus
  Cc: linux-mtd, linux-kernel
In-Reply-To: <20260601125438.3481722-2-mwalle@kernel.org>

> That flag was added in [1] to not "issue any non supported commands".
> But since we now have the generic SFDP driver, we'll issue the RDSFDP
> command on most flashes anyway and there was no single complaint. Remove
> the only user of this flag so we can rework the parameter initialization
> in the core.
> 
> [1] https://lore.kernel.org/linux-mtd/20211207140254.87681-13-tudor.ambarus@microchip.com/
> 
> Signed-off-by: Michael Walle <mwalle@kernel.org>

Reviewed-by: Takahiro Kuwano <takahiro.kuwano@infineon.com>


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox