linux-kernel - Re: [PATCH 2/3] mtd: spi-nor: sfdp: introduce smpt_map

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b5f36114-f5d2-44c4-8902-f7d7e68b29d4@linaro.org>
Date: Thu, 23 Oct 2025 08:30:23 +0100
From: Tudor Ambarus <tudor.ambarus@...aro.org>
To: Takahiro Kuwano <tkuw584924@...il.com>,
 Pratyush Yadav <pratyush@...nel.org>, Michael Walle <mwalle@...nel.org>,
 Miquel Raynal <miquel.raynal@...tlin.com>,
 Richard Weinberger <richard@....at>, Vignesh Raghavendra <vigneshr@...com>,
 Marek Vasut <marek.vasut+renesas@...lbox.org>
Cc: linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
 Takahiro Kuwano <Takahiro.Kuwano@...ineon.com>
Subject: Re: [PATCH 2/3] mtd: spi-nor: sfdp: introduce smpt_map_id fixup hook



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@...aro.org>> 
> Co-developed-by: Marek Vasut <marek.vasut+renesas@...lbox.org>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@...lbox.org>
> Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@...ineon.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
>