From: Marek Vasut <marex@nabladev.com>
To: Cheng Ming Lin <linchengming884@gmail.com>
Cc: Michael Walle <mwalle@kernel.org>,
Pratyush Yadav <pratyush@kernel.org>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Takahiro Kuwano <takahiro.kuwano@infineon.com>,
Maarten Zanders <maarten@zanders.be>,
Cheng Ming Lin <chengminglin@mxic.com.tw>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mtd: spi-nor: Describe locking support for MX25L51245G
Date: Thu, 29 Oct 2026 02:06:50 +0100 [thread overview]
Message-ID: <5c3ab7fc-2b99-4f8c-b625-1402d1f67067@nabladev.com> (raw)
In-Reply-To: <20261028081534.945416-1-linchengming884@gmail.com>
On 10/28/26 9:15 AM, Cheng Ming Lin wrote:
Hello Cheng Ming,
> On 10/24/26 2:18 AM, Marek Vasut wrote:
>> Cheng Ming , can you (or someone from Macronix) please have a look at
>> this patch and confirm that it is OK ?
>
> I checked the patch against the MX25L51245G datasheet. RDCR (0x15),
> CR bit 3 as TB, the TB bit being OTP, and the 4-BP locking scheme all
> match the datasheet, so the description is correct from our side.
>
> One concern, in line with the sashiko-bot comment: since locking is
> an optional feature, I think failing to read CR should not fail the
> probe. Controllers with a restricted opcode set (e.g. spi-intel) will
> return -EOPNOTSUPP for 0x15, and this part probes fine on them today
> with macronix_qpp4b_fixups. Rather than special-casing -EOPNOTSUPP,
> how about just leaving locking disabled on any CR read error, e.g.:
>
> /*
> * Locking is optional. If CR cannot be read (e.g. the controller
> * does not support RDCR), leave locking disabled instead of
> * failing the probe.
> */
> if (mx25l51245_read_cr(nor, nor->bouncebuf))
> return 0;
I can add an explicit check, if (ret == -EOPNOTSUPP) return 0; , that is
probably better than blanked ignore of all errors ?
> Michael, a related question for you. Maarten posted a series last
> year to make the RDCR opcode configurable in the core and use 0x15
> for Macronix:
>
> https://lore.kernel.org/linux-mtd/20250922155635.749975-1-maarten@zanders.be/
>
> It stalled because setting 0x15 for all Macronix parts is wrong (e.g.
> MX25L12805D has no RDCR), and because there was no user of RDCR at the
> time. This patch is now such a user.
>
> I have gone through the flashes currently in the Macronix ID table
> and checked which ones do not have a CR / do not support RDCR. If it
> helps, I can add this information per flash entry, so that 0x15 is
> only used for the parts that actually support it. For IDs that are
> shared by several parts, RDCR would only be enabled if all of them
> support it. That should address the concern on Maarten's series, and
> this patch could then simply use spi_nor_read_cr() instead of
> implementing its own RDCR helper in macronix.c.
>
> Would that be an acceptable direction?
I'll wait for input from Michael .
Thank you for your help !
--
Best regards,
Marek Vasut
prev parent reply other threads:[~2026-10-29 5:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-24 0:16 Marek Vasut
2026-10-24 0:18 ` Marek Vasut
2026-10-28 8:15 ` Cheng Ming Lin
2026-10-29 1:06 ` Marek Vasut [this message]
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=5c3ab7fc-2b99-4f8c-b625-1402d1f67067@nabladev.com \
--to=marex@nabladev.com \
--cc=chengminglin@mxic.com.tw \
--cc=linchengming884@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=maarten@zanders.be \
--cc=miquel.raynal@bootlin.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®