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