[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 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

[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/

[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

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

[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?

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/

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

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

[Takahiro.Kuwano]

> 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/

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

[Takahiro.Kuwano]

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

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

[Tudor Ambarus]

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

______________________________________________________
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

[Tudor Ambarus]

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

[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/

[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

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/

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>

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

[Takahiro.Kuwano]

> 
> 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/

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

[Takahiro.Kuwano]

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

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

[Tudor Ambarus]

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

______________________________________________________
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

[Tudor Ambarus]

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

[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/

[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

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

[Tudor Ambarus]

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/

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

[Tudor Ambarus]

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)

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

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/

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

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.

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/

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.

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