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

From: Cheng Ming Lin

Date: Thu May 28 2026 - 05:05:52 EST


Hi Michael,

Michael Walle <mwalle@xxxxxxxxxx> 於 2026年5月28日週四 下午3:52寫道:
>
> 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.

Got it. I will add the detailed comments in the fixup as you suggested
and prepare the v2 patch accordingly.

Besides that, I discovered another issue while reviewing the code. Since
the legacy MX25L12805D does not support SFDP, it strictly requires the
size and no_sfdp_flags to be defined in the flash_info struct. Without
these static parameters, the probe will fail for the legacy part.

Looking back at the previous effort when we submitted patches to drop
flash_info fields (shifting to rely on SFDP), the MX25L12805D was
already EOL and we had no physical stock available. At that time, we
used the MX25L12833F for verification, which inadvertently led to
mistakenly dropping the fallback parameters needed by the actual
MX25L12805D.

To resolve this, I will restore the size and no_sfdp_flags back to this
JEDEC ID entry. Since this is a fix for the legacy part, I will likely
split it into a separate patch in the v2 series and add a
Cc: stable@xxxxxxxxxxxxxxx tag so it can be properly backported.

>
> -michael

Thanks,
Cheng Ming Lin