aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux
diff options
context:
space:
mode:
authorNick Hainke <vincent@systemli.org>2020-10-25 00:52:47 +0200
committerDavid Bauer <mail@david-bauer.net>2020-10-26 02:35:55 +0100
commitc9e9b8c342d918cedfc4d2e1c2f7fd1fcaf0b56b (patch)
tree20b6c08c7a9d1a25c2c44dec2aeef2d3edebfa4a /target/linux
parentc1130c7a6bd6cde9a9984da10de0edf47161df33 (diff)
downloadupstream-c9e9b8c342d918cedfc4d2e1c2f7fd1fcaf0b56b.tar.gz
upstream-c9e9b8c342d918cedfc4d2e1c2f7fd1fcaf0b56b.tar.bz2
upstream-c9e9b8c342d918cedfc4d2e1c2f7fd1fcaf0b56b.zip
ath79: fix block protection clearing
The block protection bits of macronix do not match the implementation. The chip has 3 BP bits. Bit 5 is actually the third BP but here the 5th bit is SR_TB. Therefore the patch adds SR_TB to the mask. In the 4.19er kernel the whole register was simply set to 0. The wrong implementation did not remove the block protection. This led to jffs2 errors in the form of: "jffs2: Newly-erased block contained word 0x19852003 at offset 0x..." This caused inconsistent memory and other errors. Suggested-by: David Bauer <mail@david-bauer.net> Signed-off-by: Nick Hainke <vincent@systemli.org>
Diffstat (limited to 'target/linux')
-rw-r--r--target/linux/ath79/patches-5.4/450-fix-block-protection-clearing.patch28
1 files changed, 28 insertions, 0 deletions
diff --git a/target/linux/ath79/patches-5.4/450-fix-block-protection-clearing.patch b/target/linux/ath79/patches-5.4/450-fix-block-protection-clearing.patch
new file mode 100644
index 0000000000..a7ed62302d
--- /dev/null
+++ b/target/linux/ath79/patches-5.4/450-fix-block-protection-clearing.patch
@@ -0,0 +1,28 @@
+From: Nick Hainke <vincent@systemli.org>
+Date: Sun, 25 Oct 2020 00:52:47 +0200
+Subject: [PATCH] ath79: fix block protection clearing
+
+The block protection bits of macronix do not match the implementation.
+The chip has 3 BP bits. Bit 5 is actually the third BP but here the
+5th bit is SR_TB. Therefore the patch adds SR_TB to the mask. In the
+4.19er kernel the whole register was simply set to 0.
+
+The wrong implementation did not remove the block protection. This led
+to jffs2 errors in the form of:
+"jffs2: Newly-erased block contained word 0x19852003 at offset 0x..."
+This caused inconsistent memory and other errors.
+
+Suggested-by: David Bauer <mail@david-bauer.net>
+Signed-off-by: Nick Hainke <vincent@systemli.org>
+
+--- a/drivers/mtd/spi-nor/spi-nor.c
++++ b/drivers/mtd/spi-nor/spi-nor.c
+@@ -1981,7 +1981,7 @@ static int sr2_bit7_quad_enable(struct s
+ static int spi_nor_clear_sr_bp(struct spi_nor *nor)
+ {
+ int ret;
+- u8 mask = SR_BP2 | SR_BP1 | SR_BP0;
++ u8 mask = SR_TB | SR_BP2 | SR_BP1 | SR_BP0;
+
+ ret = read_sr(nor);
+ if (ret < 0) {