Re: [PATCH] mtd: spi-nor: allow force unlocking via DT property

["Michael Walle" <mwalle@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2339 bytes --]

On Thu Aug 6, 2026 at 1:24 PM CEST, Chen Minqiang wrote:
> 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.


Is this AI assisted?

> 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.

This patch won't fly as is. You're missing the dt-bindings patch
(which I doubt will be accepted) and I really don't like this
approach. First, why would you unlock a flash automatically? I've
worked hard, to get rid of that anti-feature. Second, what if you
still loose the flash "lottery"?

-michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]