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
next parent reply other threads:[~2026-08-06 11:24 UTC|newest]
Thread overview: 4+ 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-06 11:37 ` [PATCH v2] mtd: spi-nor: allow force unlocking via DT property 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