Re: [PATCH] mtd: spi-nor: Add support for MX25L12833F and MX25L12845G

From: "Michael Walle" <mwalle@kernel.org>
To: "Miquel Raynal" <miquel.raynal@bootlin.com>,
	"Cheng Ming Lin" <linchengming884@gmail.com>
Cc: "Pratyush Yadav" <pratyush@kernel.org>,
	"Takahiro Kuwano" <takahiro.kuwano@infineon.com>,
	"Richard Weinberger" <richard@nod.at>,
	"Vignesh Raghavendra" <vigneshr@ti.com>,
	<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
	<alvinzhou@mxic.com.tw>,
	"Cheng Ming Lin" <chengminglin@mxic.com.tw>
Subject: Re: [PATCH] mtd: spi-nor: Add support for MX25L12833F and MX25L12845G
Date: Thu, 28 May 2026 09:52:08 +0200	[thread overview]
Message-ID: <DIU5AHNXBPN2.27JOC8D5COWAM@kernel.org> (raw)
In-Reply-To: <87eciwhtf8.fsf@bootlin.com>

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

Hi,

On Thu May 28, 2026 at 9:42 AM CEST, Miquel Raynal wrote:
> Hi Cheng Ming,
>
>>> It looks like you're getting bitten by the ID reuse. You can't just
>>> unconditionally add the quad PP because as far as I can see the
>>> MX25L12805D [1] is just a standard single bit i/o flash and doesn't
>>> support the 4PP.
>>
>> You are absolutely right. Thanks for catching this.
>>
>> The MX25L12805D is indeed a much older product (released around 2009).
>> Since the initial JESD216 SFDP standard wasn't published until 2011,
>> I double-checked with our internal PM and confirmed that the MX25L12805D
>> does not support SFDP at all.
>>
>> Since the newer flashes (MX25L12833F and MX25L12845G) do support SFDP,
>> we could use this as a differentiator to distinguish them from the legacy
>> MX25L12805D.
>>
>> What if we try to read the SFDP signature (RDSFDP) in the fixup hook?
>> If a valid SFDP signature is detected, we can safely identify it as the
>> newer flash and apply the SNOR_HWCAPS_PP_1_4_4 capability. If there is
>> no SFDP signature, we leave it as is for the legacy MX25L12805D.
>>
>> Do you think this approach is feasible and acceptable? If so, I will
>> implement this logic and submit a v2 patch.
>
> The ->post_sfdp() fixup hook is documented as "not called for SPI NORs
> that do not support SFDP". Alternatively, I believe an earlier hook,
> like ->post_bfpt() could also work since it does not seem to run on
> non SFDP compatible flashes.

Moreover:

 *    spi_nor_post_sfdp_fixups() is called after the SFDP tables are parsed.
 *    It is used to tweak various flash parameters when information provided
 *    by the SFDP tables are wrong.

And it looks like that is the case for these flashes. Also, please
provide a comment on the fixup describing that the flash misses that
property. Basically, what you've written in the commit message.

-michael

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

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

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