[openwrt/openwrt] ath79: generic: disable SPI-NOR write protect unconditionally

[LEDE Commits]

nick pushed a commit to openwrt/openwrt.git, branch openwrt-23.05:
https://git.openwrt.org/c55aaa7c9a98e7c0a5e1ea8293a534dc5b395cf3

commit c55aaa7c9a98e7c0a5e1ea8293a534dc5b395cf3
Author: Lech Perczak <lech.perczak at gmail.com>
AuthorDate: Sun Dec 17 18:25:55 2023 +0100

    ath79: generic: disable SPI-NOR write protect unconditionally
    
    Kernel 5.15 introduced a significant change to spi-nor subsystem [1],
    which would the SPI-NOR core to no longer unprotect the Flash chips if
    their protection bits are non-volatile, which is the case for MX25L6405D
    and MX25L12805D, used in Ubiquiti XW and WA lines of devices [2].
    
    However, their bootloader forcibly enables this protection before
    continuing to boot, making the kernel not unprotect the flash upon boot,
    causing JFFS2 to be unable write to the filesystem. Because sysupgrade
    seems to unlock the flash explicitly, the upgrade will work, but the
    system will be unable to save configrationm showing the following symptom
    in the kernel log:
    
    [   86.168016] jffs2_scan_eraseblock(): End of filesystem marker found at 0x0
    [   86.192344] jffs2_build_filesystem(): unlocking the mtd device...
    [   86.192443] done.
    [   86.200669] jffs2_build_filesystem(): erasing all blocks after the end marker...
    [   86.220646] jffs2: Newly-erased block contained word 0x19852003 at offset 0x001e0000
    [   86.292388] jffs2: Newly-erased block contained word 0x19852003 at offset 0x001d0000
    [   86.324867] jffs2: Newly-erased block contained word 0x19852003 at offset 0x001c0000
    [   86.355316] jffs2: Newly-erased block contained word 0x19852003 at offset 0x001b0000
    [   86.402855] jffs2: Newly-erased block contained word 0x19852003 at offset 0x001a0000
    
    Disable the write protection unconditionally for ath79/generic subtarget,
    so the XW and WA devices can function again. However, this is only a
    stopgap solution - it probably should be investigated if there is a way
    to selectively unlock the area used by rootfs_data - but given the lock
    granularity, this seems unlikely.
    
    With this patch in place, rootfs_data partition on my Nanostation Loco
    M5 XW is writable again.
    
    Fixes: #12882
    Fixes: #13750
    Fixes: 579703f38c14 ("ath79: switch to 5.15 as default kernel")
    Link: http://www.infradead.org/pipermail/linux-mtd/2020-October/082805.html
    Link: https://forum.openwrt.org/t/powerbeam-m5-xw-configuration-loss-after-reboot/141925
    Signed-off-by: Lech Perczak <lech.perczak at gmail.com>
    
    (cherry picked from commit f024f4b1b0380b3b2e18115bd8e4f35393fccc70)
    Signed-off-by: Lech Perczak <lech.perczak at gmail.com>
---
 target/linux/ath79/generic/config-default | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/linux/ath79/generic/config-default b/target/linux/ath79/generic/config-default
index 06f264b626..09ea9d93d7 100644
--- a/target/linux/ath79/generic/config-default
+++ b/target/linux/ath79/generic/config-default
@@ -14,6 +14,8 @@ CONFIG_LEDS_RESET=y
 CONFIG_MARVELL_PHY=y
 CONFIG_MICREL_PHY=y
 CONFIG_MTD_REDBOOT_PARTS=y
+CONFIG_MTD_SPI_NOR_SWP_DISABLE=y
+# CONFIG_MTD_SPI_NOR_SWP_DISABLE_ON_VOLATILE is not set
 CONFIG_MTD_SPLIT_EVA_FW=y
 CONFIG_NVMEM_SYSFS=y
 CONFIG_NVMEM_U_BOOT_ENV=y