[PATCH 0/3] mtd: spi-nor: spansion: Add SMPT fixup for S25FS-S

[PATCH 0/3] mtd: spi-nor: spansion: Add SMPT fixup for S25FS-S

[Takahiro Kuwano]

Suggest new series as the result of discussion in the thread:
https://patchwork.ozlabs.org/project/linux-mtd/patch/20240914220859.128540-1-marek.vasut+renesas@mailbox.org/

Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
---
Takahiro Kuwano (3):
      mtd: spi-nor: sfdp: introduce smpt_read_dummy fixup hook
      mtd: spi-nor: sfdp: introduce smpt_map_id fixup hook
      mtd: spi-nor: spansion: SMPT fixups for S25FS-S

 drivers/mtd/spi-nor/core.h     |  6 ++++++
 drivers/mtd/spi-nor/sfdp.c     | 30 ++++++++++++++++++++++++++++--
 drivers/mtd/spi-nor/spansion.c | 34 ++++++++++++++++++++++++++++++++++
 3 files changed, 68 insertions(+), 2 deletions(-)
---
base-commit: 17926cd770ec837ed27d9856cf07f2da8dda4131
change-id: 20251022-s25fs-s-smpt-fixup-dc97e81574b1

Best regards,
-- 
Takahiro Kuwano <Takahiro.Kuwano@infineon.com>

[PATCH 1/3] mtd: spi-nor: sfdp: introduce smpt_read_dummy fixup hook

[Takahiro Kuwano]

SMPT contains config detection info that descibes opcode, address, and
dummy cycles to read sector map config. The dummy cycles parameter can
be 'variable' and should be determined in device specific fixup hook.

Inroduce smpt_read_dummy() in struct spi_nor_fixups. It is called when
the dummy cycle field in SMPT config detection is 'varialble'.

Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
---
 drivers/mtd/spi-nor/core.h |  3 +++
 drivers/mtd/spi-nor/sfdp.c | 18 ++++++++++++++++--
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index ceff412f7d65ab7b856795ca5c092cddbf598cd6..5ad46d95d09cc9d527f71579a71eed210e726f68 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -409,6 +409,8 @@ struct spi_nor_flash_parameter {
  *                flash parameters when information provided by the flash_info
  *                table is incomplete or wrong.
  * @post_bfpt: called after the BFPT table has been parsed
+ * @smpt_read_dummy: called during SMPT table is being parsed. Used to fix the
+ *                   number of dummy cycles in read register ops.
  * @post_sfdp: called after SFDP has been parsed (is also called for SPI NORs
  *             that do not support RDSFDP). Typically used to tweak various
  *             parameters that could not be extracted by other means (i.e.
@@ -426,6 +428,7 @@ struct spi_nor_fixups {
 	int (*post_bfpt)(struct spi_nor *nor,
 			 const struct sfdp_parameter_header *bfpt_header,
 			 const struct sfdp_bfpt *bfpt);
+	void (*smpt_read_dummy)(const struct spi_nor *nor, u8 *read_dummy);
 	int (*post_sfdp)(struct spi_nor *nor);
 	int (*late_init)(struct spi_nor *nor);
 };
diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index 21727f9a4ac6926080a116e30830c9533122fdad..9a47dcaca06ae2ad85ac8503658083b1d56d8b96 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -699,6 +699,17 @@ static u8 spi_nor_smpt_addr_nbytes(const struct spi_nor *nor, const u32 settings
 	}
 }
 
+static void spi_nor_smpt_read_dummy_fixups(const struct spi_nor *nor,
+					   u8 *read_dummy)
+{
+	if (nor->manufacturer && nor->manufacturer->fixups &&
+	    nor->manufacturer->fixups->smpt_read_dummy)
+		nor->manufacturer->fixups->smpt_read_dummy(nor, read_dummy);
+
+	if (nor->info->fixups && nor->info->fixups->smpt_read_dummy)
+		nor->info->fixups->smpt_read_dummy(nor, read_dummy);
+}
+
 /**
  * spi_nor_smpt_read_dummy() - return the configuration detection command read
  *			       latency, in clock cycles.
@@ -711,8 +722,11 @@ static u8 spi_nor_smpt_read_dummy(const struct spi_nor *nor, const u32 settings)
 {
 	u8 read_dummy = SMPT_CMD_READ_DUMMY(settings);
 
-	if (read_dummy == SMPT_CMD_READ_DUMMY_IS_VARIABLE)
-		return nor->read_dummy;
+	if (read_dummy == SMPT_CMD_READ_DUMMY_IS_VARIABLE) {
+		read_dummy = nor->read_dummy;
+		spi_nor_smpt_read_dummy_fixups(nor, &read_dummy);
+	}
+
 	return read_dummy;
 }
 

-- 
2.34.1

Re: [PATCH 1/3] mtd: spi-nor: sfdp: introduce smpt_read_dummy fixup hook

[Tudor Ambarus]

Hi, Takahiro,

On 10/22/25 11:07 AM, Takahiro Kuwano wrote:
> SMPT contains config detection info that descibes opcode, address, and

typo: describes> dummy cycles to read sector map config. The dummy cycles parameter can
> be 'variable' and should be determined in device specific fixup hook.

This doesn't describe why we need the hook. I'd advise to describe what
value has nor->read_dummy before the fixup hook (zero you said), why the
zero value does always fit some flashes like the IFX one, which for that
particular read reg command it always needs 8 dummy cycles. This also
reveals that the SMPT table on that flash instead of defining
SMPT_CMD_READ_DUMMY_IS_VARIABLE is should have actually used the number of
needed dummy cycles: 8.

Please adapt and add something around these lines, otherwise in 5 years
from now we'll forget what was this about.

The patch looks okay to me.
Cheers,
ta

> 
> Inroduce smpt_read_dummy() in struct spi_nor_fixups. It is called when
> the dummy cycle field in SMPT config detection is 'varialble'.
> 
> Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
> ---
>  drivers/mtd/spi-nor/core.h |  3 +++
>  drivers/mtd/spi-nor/sfdp.c | 18 ++++++++++++++++--
>  2 files changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index ceff412f7d65ab7b856795ca5c092cddbf598cd6..5ad46d95d09cc9d527f71579a71eed210e726f68 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -409,6 +409,8 @@ struct spi_nor_flash_parameter {
>   *                flash parameters when information provided by the flash_info
>   *                table is incomplete or wrong.
>   * @post_bfpt: called after the BFPT table has been parsed
> + * @smpt_read_dummy: called during SMPT table is being parsed. Used to fix the
> + *                   number of dummy cycles in read register ops.
>   * @post_sfdp: called after SFDP has been parsed (is also called for SPI NORs
>   *             that do not support RDSFDP). Typically used to tweak various
>   *             parameters that could not be extracted by other means (i.e.
> @@ -426,6 +428,7 @@ struct spi_nor_fixups {
>  	int (*post_bfpt)(struct spi_nor *nor,
>  			 const struct sfdp_parameter_header *bfpt_header,
>  			 const struct sfdp_bfpt *bfpt);
> +	void (*smpt_read_dummy)(const struct spi_nor *nor, u8 *read_dummy);
>  	int (*post_sfdp)(struct spi_nor *nor);
>  	int (*late_init)(struct spi_nor *nor);
>  };
> diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
> index 21727f9a4ac6926080a116e30830c9533122fdad..9a47dcaca06ae2ad85ac8503658083b1d56d8b96 100644
> --- a/drivers/mtd/spi-nor/sfdp.c
> +++ b/drivers/mtd/spi-nor/sfdp.c
> @@ -699,6 +699,17 @@ static u8 spi_nor_smpt_addr_nbytes(const struct spi_nor *nor, const u32 settings
>  	}
>  }
>  
> +static void spi_nor_smpt_read_dummy_fixups(const struct spi_nor *nor,
> +					   u8 *read_dummy)
> +{
> +	if (nor->manufacturer && nor->manufacturer->fixups &&
> +	    nor->manufacturer->fixups->smpt_read_dummy)
> +		nor->manufacturer->fixups->smpt_read_dummy(nor, read_dummy);
> +
> +	if (nor->info->fixups && nor->info->fixups->smpt_read_dummy)
> +		nor->info->fixups->smpt_read_dummy(nor, read_dummy);
> +}
> +
>  /**
>   * spi_nor_smpt_read_dummy() - return the configuration detection command read
>   *			       latency, in clock cycles.
> @@ -711,8 +722,11 @@ static u8 spi_nor_smpt_read_dummy(const struct spi_nor *nor, const u32 settings)
>  {
>  	u8 read_dummy = SMPT_CMD_READ_DUMMY(settings);
>  
> -	if (read_dummy == SMPT_CMD_READ_DUMMY_IS_VARIABLE)
> -		return nor->read_dummy;
> +	if (read_dummy == SMPT_CMD_READ_DUMMY_IS_VARIABLE) {
> +		read_dummy = nor->read_dummy;
> +		spi_nor_smpt_read_dummy_fixups(nor, &read_dummy);
> +	}
> +
>  	return read_dummy;
>  }
>  
> 

Re: [PATCH 1/3] mtd: spi-nor: sfdp: introduce smpt_read_dummy fixup hook

[Tudor Ambarus]

On 10/23/25 8:25 AM, Tudor Ambarus wrote:
> The patch looks okay to me.
with a bit of more context into the commit message, you can also add:
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>

[PATCH 2/3] mtd: spi-nor: sfdp: introduce smpt_map_id fixup hook

[Takahiro Kuwano]

Some chips have inconsistency in SMPT that derives wrong map ID and
fails to detect correct sector map. Introduce smpt_map_id() into
struct spi_nor_fixups. That is called after map ID detection by SMPT
and chip specific implementation can correct map ID.

Co-developed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
---
 drivers/mtd/spi-nor/core.h |  3 +++
 drivers/mtd/spi-nor/sfdp.c | 12 ++++++++++++
 2 files changed, 15 insertions(+)

diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index 5ad46d95d09cc9d527f71579a71eed210e726f68..16b382d4f04f207aa26190ed8bdf2d19885f7315 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -411,6 +411,8 @@ struct spi_nor_flash_parameter {
  * @post_bfpt: called after the BFPT table has been parsed
  * @smpt_read_dummy: called during SMPT table is being parsed. Used to fix the
  *                   number of dummy cycles in read register ops.
+ * @smpt_map_id: called after map ID in SMPT table has been determined for the
+ *               case the map ID is wrong and needs to be fixed.
  * @post_sfdp: called after SFDP has been parsed (is also called for SPI NORs
  *             that do not support RDSFDP). Typically used to tweak various
  *             parameters that could not be extracted by other means (i.e.
@@ -429,6 +431,7 @@ struct spi_nor_fixups {
 			 const struct sfdp_parameter_header *bfpt_header,
 			 const struct sfdp_bfpt *bfpt);
 	void (*smpt_read_dummy)(const struct spi_nor *nor, u8 *read_dummy);
+	void (*smpt_map_id)(const struct spi_nor *nor, u8 *map_id);
 	int (*post_sfdp)(struct spi_nor *nor);
 	int (*late_init)(struct spi_nor *nor);
 };
diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index 9a47dcaca06ae2ad85ac8503658083b1d56d8b96..a8324c2da0acf2953a4a62e2a9f7ed31fcd8b4f2 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -730,6 +730,16 @@ static u8 spi_nor_smpt_read_dummy(const struct spi_nor *nor, const u32 settings)
 	return read_dummy;
 }
 
+static void spi_nor_smpt_map_id_fixups(const struct spi_nor *nor, u8 *map_id)
+{
+	if (nor->manufacturer && nor->manufacturer->fixups &&
+	    nor->manufacturer->fixups->smpt_map_id)
+		nor->manufacturer->fixups->smpt_map_id(nor, map_id);
+
+	if (nor->info->fixups && nor->info->fixups->smpt_map_id)
+		nor->info->fixups->smpt_map_id(nor, map_id);
+}
+
 /**
  * spi_nor_get_map_in_use() - get the configuration map in use
  * @nor:	pointer to a 'struct spi_nor'
@@ -783,6 +793,8 @@ static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt,
 		map_id = map_id << 1 | !!(*buf & read_data_mask);
 	}
 
+	spi_nor_smpt_map_id_fixups(nor, &map_id);
+
 	/*
 	 * If command descriptors are provided, they always precede map
 	 * descriptors in the table. There is no need to start the iteration

-- 
2.34.1

Re: [PATCH 2/3] mtd: spi-nor: sfdp: introduce smpt_map_id fixup hook

[Tudor Ambarus]

On 10/22/25 11:07 AM, Takahiro Kuwano wrote:
> Some chips have inconsistency in SMPT that derives wrong map ID and
> fails to detect correct sector map. Introduce smpt_map_id() into
> struct spi_nor_fixups. That is called after map ID detection by SMPT
> and chip specific implementation can correct map ID.

You may reword the commit message a bit:
Certain chips have inconsistent Serial Mapping Parameter Table (SMPT)
data, which leads to the wrong map ID being identified, causing failures
to detect the correct sector map.

To fix this, introduce smpt_map_id() into the struct spi_nor_fixups.
This function will be called after the initial SMPT-based detection,
allowing chip-specific logic to correct the map ID.

And maybe give an example which flash needs it.

Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>> 
> Co-developed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
> ---
>  drivers/mtd/spi-nor/core.h |  3 +++
>  drivers/mtd/spi-nor/sfdp.c | 12 ++++++++++++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index 5ad46d95d09cc9d527f71579a71eed210e726f68..16b382d4f04f207aa26190ed8bdf2d19885f7315 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -411,6 +411,8 @@ struct spi_nor_flash_parameter {
>   * @post_bfpt: called after the BFPT table has been parsed
>   * @smpt_read_dummy: called during SMPT table is being parsed. Used to fix the
>   *                   number of dummy cycles in read register ops.
> + * @smpt_map_id: called after map ID in SMPT table has been determined for the
> + *               case the map ID is wrong and needs to be fixed.
>   * @post_sfdp: called after SFDP has been parsed (is also called for SPI NORs
>   *             that do not support RDSFDP). Typically used to tweak various
>   *             parameters that could not be extracted by other means (i.e.
> @@ -429,6 +431,7 @@ struct spi_nor_fixups {
>  			 const struct sfdp_parameter_header *bfpt_header,
>  			 const struct sfdp_bfpt *bfpt);
>  	void (*smpt_read_dummy)(const struct spi_nor *nor, u8 *read_dummy);
> +	void (*smpt_map_id)(const struct spi_nor *nor, u8 *map_id);
>  	int (*post_sfdp)(struct spi_nor *nor);
>  	int (*late_init)(struct spi_nor *nor);
>  };
> diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
> index 9a47dcaca06ae2ad85ac8503658083b1d56d8b96..a8324c2da0acf2953a4a62e2a9f7ed31fcd8b4f2 100644
> --- a/drivers/mtd/spi-nor/sfdp.c
> +++ b/drivers/mtd/spi-nor/sfdp.c
> @@ -730,6 +730,16 @@ static u8 spi_nor_smpt_read_dummy(const struct spi_nor *nor, const u32 settings)
>  	return read_dummy;
>  }
>  
> +static void spi_nor_smpt_map_id_fixups(const struct spi_nor *nor, u8 *map_id)
> +{
> +	if (nor->manufacturer && nor->manufacturer->fixups &&
> +	    nor->manufacturer->fixups->smpt_map_id)
> +		nor->manufacturer->fixups->smpt_map_id(nor, map_id);
> +
> +	if (nor->info->fixups && nor->info->fixups->smpt_map_id)
> +		nor->info->fixups->smpt_map_id(nor, map_id);
> +}
> +
>  /**
>   * spi_nor_get_map_in_use() - get the configuration map in use
>   * @nor:	pointer to a 'struct spi_nor'
> @@ -783,6 +793,8 @@ static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt,
>  		map_id = map_id << 1 | !!(*buf & read_data_mask);
>  	}
>  
> +	spi_nor_smpt_map_id_fixups(nor, &map_id);
> +
>  	/*
>  	 * If command descriptors are provided, they always precede map
>  	 * descriptors in the table. There is no need to start the iteration
> 

[PATCH 3/3] mtd: spi-nor: spansion: SMPT fixups for S25FS-S

[Takahiro Kuwano]

S25FS-S family supports SMPT that helps to detect sector layout settings
in configuration registers, but some of parameters in the table are
wrong or undetermined so the fixups below are required.

Read Any Register op is used to read configuration registers that
related to sector map. The op requires 8 cycles latency by default.
Implement smpt_read_dummy() to set correct dummy cycles.

Map ID is structured by combination of CR3NV[3], CR1NV[2], and CR3NV[1].
However, in S25FS512S, CR3NV[1] is RFU and always 0, while map IDs
defined in the table assume it is always 1. Implement smpt_map_id() to
fix map ID for S25FS512S. Other densities in S25FS-S family (256Mb and
128Mb) don't need this fix as CR3NV[1] in those chips is configurable
and map IDs are correctly defined in SMPT.

Co-developed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
---
 drivers/mtd/spi-nor/spansion.c | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/drivers/mtd/spi-nor/spansion.c b/drivers/mtd/spi-nor/spansion.c
index a0296c871634678be509cb30d26e18debff3066d..89e85eba2c31a4d74dcbfeffdeff7139b6e0f6b1 100644
--- a/drivers/mtd/spi-nor/spansion.c
+++ b/drivers/mtd/spi-nor/spansion.c
@@ -785,8 +785,42 @@ s25fs_s_nor_post_bfpt_fixups(struct spi_nor *nor,
 	return 0;
 }
 
+static void s25fs_s_nor_smpt_read_dummy(const struct spi_nor *nor,
+					u8 *read_dummy)
+{
+	/*
+	 * The configuration detection dwords in S25FS-S SMPT has 65h as
+	 * command instruction and 'variable' as configuration detection command
+	 * latency. Set 8 dummy cycles as it is factory default for 65h (read
+	 * any register) op.
+	 */
+	*read_dummy = 8;
+}
+
+static void s25fs_s_nor_smpt_map_id_dummy(const struct spi_nor *nor, u8 *map_id)
+{
+	/*
+	 * The S25FS512S chip datasheet rev.O Table 71 on page 153
+	 * JEDEC Sector Map Parameter Dword-6 Config. Detect-3 does
+	 * use CR3NV bit 1 to discern 64kiB/256kiB uniform sectors
+	 * device configuration, however according to section 7.5.5.1
+	 * Configuration Register 3 Non-volatile (CR3NV) page 61, the
+	 * CR3NV bit 1 is RFU Reserved for Future Use, and is set to
+	 * 0 on newly manufactured devices, which means 64kiB sectors.
+	 * Since the device does not support 64kiB uniform sectors in
+	 * any configuration, parsing SMPT table cannot find a valid
+	 * sector map entry and fails. Fix this up by setting SMPT
+	 * configuration index bit 0, which is populated exactly by
+	 * the CR3NV bit 1 being 1.
+	 */
+	if (nor->params->size == SZ_64M)
+		*map_id |= BIT(0);
+}
+
 static const struct spi_nor_fixups s25fs_s_nor_fixups = {
 	.post_bfpt = s25fs_s_nor_post_bfpt_fixups,
+	.smpt_read_dummy = s25fs_s_nor_smpt_read_dummy,
+	.smpt_map_id = s25fs_s_nor_smpt_map_id_dummy,
 };
 
 static const struct flash_info spansion_nor_parts[] = {

-- 
2.34.1

Re: [PATCH 3/3] mtd: spi-nor: spansion: SMPT fixups for S25FS-S

[Tudor Ambarus]

On 10/22/25 11:07 AM, Takahiro Kuwano wrote:
> S25FS-S family supports SMPT that helps to detect sector layout settings
> in configuration registers, but some of parameters in the table are
> wrong or undetermined so the fixups below are required.
> 
> Read Any Register op is used to read configuration registers that
> related to sector map. The op requires 8 cycles latency by default.
> Implement smpt_read_dummy() to set correct dummy cycles.
> 
> Map ID is structured by combination of CR3NV[3], CR1NV[2], and CR3NV[1].
> However, in S25FS512S, CR3NV[1] is RFU and always 0, while map IDs
> defined in the table assume it is always 1. Implement smpt_map_id() to
> fix map ID for S25FS512S. Other densities in S25FS-S family (256Mb and
> 128Mb) don't need this fix as CR3NV[1] in those chips is configurable
> and map IDs are correctly defined in SMPT.
> 
> Co-developed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
> ---
>  drivers/mtd/spi-nor/spansion.c | 34 ++++++++++++++++++++++++++++++++++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/drivers/mtd/spi-nor/spansion.c b/drivers/mtd/spi-nor/spansion.c
> index a0296c871634678be509cb30d26e18debff3066d..89e85eba2c31a4d74dcbfeffdeff7139b6e0f6b1 100644
> --- a/drivers/mtd/spi-nor/spansion.c
> +++ b/drivers/mtd/spi-nor/spansion.c
> @@ -785,8 +785,42 @@ s25fs_s_nor_post_bfpt_fixups(struct spi_nor *nor,
>  	return 0;
>  }
>  
> +static void s25fs_s_nor_smpt_read_dummy(const struct spi_nor *nor,
> +					u8 *read_dummy)
> +{
> +	/*
> +	 * The configuration detection dwords in S25FS-S SMPT has 65h as
> +	 * command instruction and 'variable' as configuration detection command
> +	 * latency. Set 8 dummy cycles as it is factory default for 65h (read
> +	 * any register) op.
> +	 */
> +	*read_dummy = 8;
> +}
> +
> +static void s25fs_s_nor_smpt_map_id_dummy(const struct spi_nor *nor, u8 *map_id)
> +{
> +	/*
> +	 * The S25FS512S chip datasheet rev.O Table 71 on page 153
> +	 * JEDEC Sector Map Parameter Dword-6 Config. Detect-3 does
> +	 * use CR3NV bit 1 to discern 64kiB/256kiB uniform sectors

you need to update the comment, there's no 64 Kib uniform sectors in
the flash, the comment is misleading. You have:
- Hybrid sector option
• Physical set of eight 4-KB sectors and one 224-KB sector at the top or bottom of address space with all
remaining sectors of 256-KB
- Uniform sector option
• Uniform 256-KB blocks> +	 * device configuration, however according to section 7.5.5.1
> +	 * Configuration Register 3 Non-volatile (CR3NV) page 61, the
> +	 * CR3NV bit 1 is RFU Reserved for Future Use, and is set to
> +	 * 0 on newly manufactured devices, which means 64kiB sectors.
here too> +	 * Since the device does not support 64kiB uniform sectors in
again> +	 * any configuration, parsing SMPT table cannot find a valid
> +	 * sector map entry and fails. Fix this up by setting SMPT

by overwriting the CR3NV[1] value to 1, as the table expects.


The patch looks good, with these minor things addressed. Please fix them
and add
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>

Thanks for taking care of this, Takahiro!
Cheers,
ta

> +	 * configuration index bit 0, which is populated exactly by
> +	 * the CR3NV bit 1 being 1.
> +	 */
> +	if (nor->params->size == SZ_64M)
> +		*map_id |= BIT(0);
> +}
> +
>  static const struct spi_nor_fixups s25fs_s_nor_fixups = {
>  	.post_bfpt = s25fs_s_nor_post_bfpt_fixups,
> +	.smpt_read_dummy = s25fs_s_nor_smpt_read_dummy,
> +	.smpt_map_id = s25fs_s_nor_smpt_map_id_dummy,
>  };
>  
>  static const struct flash_info spansion_nor_parts[] = {
> 

Re: [PATCH 0/3] mtd: spi-nor: spansion: Add SMPT fixup for S25FS-S

[Marek Vasut]

On 10/22/25 12:07 PM, Takahiro Kuwano wrote:
> Suggest new series as the result of discussion in the thread:
> https://patchwork.ozlabs.org/project/linux-mtd/patch/20240914220859.128540-1-marek.vasut+renesas@mailbox.org/
> 
> Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
> ---
> Takahiro Kuwano (3):
>        mtd: spi-nor: sfdp: introduce smpt_read_dummy fixup hook
>        mtd: spi-nor: sfdp: introduce smpt_map_id fixup hook
>        mtd: spi-nor: spansion: SMPT fixups for S25FS-S
I can provide:

Tested-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # S25FS512S

Thank you for your help !