From: Chen Minqiang <ptpt52@gmail.com>
To: Pratyush Yadav <pratyush@kernel.org>,
Michael Walle <mwalle@kernel.org>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>
Cc: Takahiro Kuwano <takahiro.kuwano@infineon.com>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mtd: spi-nor: allow force unlocking via DT property
Date: Thu, 6 Aug 2026 19:24:18 +0800 [thread overview]
Message-ID: <20260806112418.14695-1-ptpt52@gmail.com> (raw)
In-Reply-To: <2026-08-05171214.2934-1-ptpt52@gmail.com>
Hi,
Thank you for your valuable insight!
You are completely right that for unlisted/generic chips that feature a 4-bit
BP layout (BP3 at bit 5 or bit 6) or a CMP (Complement Protect) bit in SR2,
spi_nor_unlock() won't clear those extra bits without the corresponding flags
(SNOR_F_HAS_4BIT_BP / SNOR_F_HAS_SR2_CMP_BIT6) set by the ID database or SFDP.
However, in practice:
1. The vast majority of 3.3V/1.8V generic SPI NOR flashes (e.g. 4MB-16MB chips
commonly found in vendor devices like Tenda AX12L Pro) use the standard
3-bit BP (BP0-BP2, SR1 bits 2..4).
2. The current main issue is that even for these standard 3-bit BP chips, the
kernel currently skips spi_nor_try_unlock_all() completely at boot time if
CONFIG_MTD_SPI_NOR_SWP_DISABLE_ON_VOLATILE is set (for non-volatile chips)
or if SNOR_F_HAS_LOCK is not set in chip flags. As a result, status registers
locked by factory bootloaders are never cleared.
`linux,force-sr-unlock` serves as a pragmatic DT override to force the unlock
attempt at probe time.
To address your point regarding 4-bit BP and CMP bits for unlisted chips, we
have two potential options:
Option A (Current Best-Effort):
Keep the patch as-is, treating `linux,force-sr-unlock` as a best-effort DT
trigger to invoke standard spi_nor_unlock(). It successfully unlocks the vast
majority of standard 3-bit BP generic chips. For rare unlisted chips with 4-bit
BP or CMP bits, explicit entries can still be added to the ID database when
discovered.
Option B (Aggressive Force-Clear):
When `linux,force-sr-unlock` is present in DT, enhance spi_nor_try_unlock_all()
to perform a broader clear operation on SR1 (masking bits 2..6 to clear BP0-BP3/TB)
and SR2 (clearing CMP bit if SR2 is readable).
Which approach would you prefer? I'd be happy to revise the patch based on your
guidance.
Best regards,
Chen Minqiang
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next parent reply other threads:[~2026-08-06 11:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2026-08-05171214.2934-1-ptpt52@gmail.com>
2026-08-06 11:24 ` Chen Minqiang [this message]
2026-08-10 6:30 ` [PATCH] mtd: spi-nor: allow force unlocking via DT property Michael Walle
2026-08-06 11:37 ` [PATCH v2] " Chen Minqiang
2026-08-05 17:12 [PATCH] " Chen Minqiang
2026-08-06 5:41 ` Takahiro.Kuwano
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=20260806112418.14695-1-ptpt52@gmail.com \
--to=ptpt52@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--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;
as well as URLs for NNTP newsgroup(s).