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

[Chen Minqiang]

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