Re: [PATCH] mtd: spi-nor: allow force unlocking via DT property
Chen Minqiang <[email protected]>
| Newsgroups | org.infradead.lists.linux-mtd,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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/