[RFC PATCH 0/3] mtd: spi-nor: Rework flash parameter initialization

[RFC PATCH 0/3] mtd: spi-nor: Rework flash parameter initialization

[Michael Walle]

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.

Michael Walle (3):
  mtd: spi-nor: spansion: s25fl256s0: remove SKIP_SFDP flag
  mtd: spi-nor: don't clear the SNOR_F_4B_OPCODES flag on failure
  mtd: spi-nor: rework flash parameter initialization

 drivers/mtd/spi-nor/core.c     | 67 +++++++++++-----------------------
 drivers/mtd/spi-nor/core.h     |  1 -
 drivers/mtd/spi-nor/spansion.c |  2 +-
 3 files changed, 23 insertions(+), 47 deletions(-)

-- 
2.47.3


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

[RFC PATCH 1/3] mtd: spi-nor: spansion: s25fl256s0: remove SKIP_SFDP flag

[Michael Walle]

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>
---
 drivers/mtd/spi-nor/spansion.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/spansion.c b/drivers/mtd/spi-nor/spansion.c
index 65227d989de1..092450375d4e 100644
--- a/drivers/mtd/spi-nor/spansion.c
+++ b/drivers/mtd/spi-nor/spansion.c
@@ -868,7 +868,7 @@ static const struct flash_info spansion_nor_parts[] = {
 		.name = "s25fl256s0",
 		.size = SZ_32M,
 		.sector_size = SZ_256K,
-		.no_sfdp_flags = SPI_NOR_SKIP_SFDP | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
+		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
 		.mfr_flags = USE_CLSR,
 	}, {
 		.id = SNOR_ID(0x01, 0x02, 0x19, 0x4d, 0x00, 0x81),
-- 
2.47.3


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

Re: [RFC PATCH 1/3] mtd: spi-nor: spansion: s25fl256s0: remove SKIP_SFDP flag

[Miquel Raynal]

Hi Michael,

> diff --git a/drivers/mtd/spi-nor/spansion.c b/drivers/mtd/spi-nor/spansion.c
> index 65227d989de1..092450375d4e 100644
> --- a/drivers/mtd/spi-nor/spansion.c
> +++ b/drivers/mtd/spi-nor/spansion.c
> @@ -868,7 +868,7 @@ static const struct flash_info spansion_nor_parts[] = {
>  		.name = "s25fl256s0",
>  		.size = SZ_32M,
>  		.sector_size = SZ_256K,
> -		.no_sfdp_flags = SPI_NOR_SKIP_SFDP | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
> +		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
>  		.mfr_flags = USE_CLSR,
>  	}, {
>  		.id = SNOR_ID(0x01, 0x02, 0x19, 0x4d, 0x00, 0x81),

Fine by me. I believe the expected behaviour should just be an empty
feedback, leading to the SFDP to be invalid and thus SFDP parsing
skipped, right?

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

Re: [RFC PATCH 1/3] mtd: spi-nor: spansion: s25fl256s0: remove SKIP_SFDP flag

[Michael Walle]

On Tue Jun 2, 2026 at 11:57 AM CEST, Miquel Raynal wrote:
> Hi Michael,
>
>> diff --git a/drivers/mtd/spi-nor/spansion.c b/drivers/mtd/spi-nor/spansion.c
>> index 65227d989de1..092450375d4e 100644
>> --- a/drivers/mtd/spi-nor/spansion.c
>> +++ b/drivers/mtd/spi-nor/spansion.c
>> @@ -868,7 +868,7 @@ static const struct flash_info spansion_nor_parts[] = {
>>  		.name = "s25fl256s0",
>>  		.size = SZ_32M,
>>  		.sector_size = SZ_256K,
>> -		.no_sfdp_flags = SPI_NOR_SKIP_SFDP | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
>> +		.no_sfdp_flags = SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ,
>>  		.mfr_flags = USE_CLSR,
>>  	}, {
>>  		.id = SNOR_ID(0x01, 0x02, 0x19, 0x4d, 0x00, 0x81),
>
> Fine by me. I believe the expected behaviour should just be an empty
> feedback, leading to the SFDP to be invalid and thus SFDP parsing
> skipped, right?

Right. Probably it will read all ones or all zeros and the parsing
will fail and skipped.

-michael

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

[RFC PATCH 2/3] mtd: spi-nor: don't clear the SNOR_F_4B_OPCODES flag on failure

[Michael Walle]

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>
---
 drivers/mtd/spi-nor/core.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 4046e137531f..fbf8c2d9c6b5 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -3066,10 +3066,8 @@ static void spi_nor_sfdp_init_params_deprecated(struct spi_nor *nor)
 
 	memcpy(&sfdp_params, nor->params, sizeof(sfdp_params));
 
-	if (spi_nor_parse_sfdp(nor)) {
+	if (spi_nor_parse_sfdp(nor))
 		memcpy(nor->params, &sfdp_params, sizeof(*nor->params));
-		nor->flags &= ~SNOR_F_4B_OPCODES;
-	}
 }
 
 /**
-- 
2.47.3


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

Re: [RFC PATCH 2/3] mtd: spi-nor: don't clear the SNOR_F_4B_OPCODES flag on failure

[Miquel Raynal]

On 01/06/2026 at 14:52:44 +02, Michael Walle <mwalle@kernel.org> wrote:

> 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: Miquel Raynal <miquel.raynal@bootlin.com>

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

[RFC PATCH 3/3] mtd: spi-nor: rework flash parameter initialization

[Michael Walle]

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).

[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);
+	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)
 #define SECT_4K				BIT(1)
 #define SPI_NOR_DUAL_READ		BIT(3)
 #define SPI_NOR_QUAD_READ		BIT(4)
-- 
2.47.3


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

Re: [RFC PATCH 0/3] mtd: spi-nor: Rework flash parameter initialization

[Miquel Raynal]

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.

Thanks,
Miquèl

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

RE: [RFC PATCH 0/3] mtd: spi-nor: Rework flash parameter initialization

[Takahiro.Kuwano]

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.

Thanks,
Takahiro

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