From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Cheng Ming Lin <linchengming884@gmail.com>
Cc: Michael Walle <mwalle@kernel.org>,
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:42:03 +0200 [thread overview]
Message-ID: <87eciwhtf8.fsf@bootlin.com> (raw)
In-Reply-To: <CAAyq3SY86mVwYtQMqhcZHjTxiD93awQZPDzHr8e5-+B9caNgbA@mail.gmail.com> (Cheng Ming Lin's message of "Thu, 28 May 2026 15:19:36 +0800")
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.
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Cheng Ming Lin <linchengming884@gmail.com>
Cc: Michael Walle <mwalle@kernel.org>,
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:42:03 +0200 [thread overview]
Message-ID: <87eciwhtf8.fsf@bootlin.com> (raw)
In-Reply-To: <CAAyq3SY86mVwYtQMqhcZHjTxiD93awQZPDzHr8e5-+B9caNgbA@mail.gmail.com> (Cheng Ming Lin's message of "Thu, 28 May 2026 15:19:36 +0800")
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.
Thanks,
Miquèl
next prev parent reply other threads:[~2026-05-28 7:42 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-28 5:17 [PATCH] mtd: spi-nor: Add support for MX25L12833F and MX25L12845G Cheng Ming Lin
2026-05-28 5:17 ` Cheng Ming Lin
2026-05-28 6:36 ` Michael Walle
2026-05-28 6:36 ` Michael Walle
2026-05-28 7:19 ` Cheng Ming Lin
2026-05-28 7:19 ` Cheng Ming Lin
2026-05-28 7:42 ` Miquel Raynal [this message]
2026-05-28 7:42 ` Miquel Raynal
2026-05-28 7:52 ` Michael Walle
2026-05-28 7:52 ` Michael Walle
2026-05-28 9:00 ` Cheng Ming Lin
2026-05-28 9:00 ` Cheng Ming Lin
2026-06-01 0:56 ` Cheng Ming Lin
2026-06-01 0:56 ` Cheng Ming Lin
2026-06-01 12:57 ` Michael Walle
2026-06-01 12:57 ` Michael Walle
2026-06-02 6:15 ` Cheng Ming Lin
2026-06-02 6:15 ` Cheng Ming Lin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87eciwhtf8.fsf@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=alvinzhou@mxic.com.tw \
--cc=chengminglin@mxic.com.tw \
--cc=linchengming884@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=mwalle@kernel.org \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=takahiro.kuwano@infineon.com \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.