kernel: move three accepted patches from pending to backports

311-MIPS-zboot-put-appended-dtb-into-a-section.patch
commit d2e850e96183 in kernel, part of v5.11

499-mtd-don-t-lock-when-recursively-deleting-partitions.patch
commit cb4543054c5c in kernel, part of v5.13

103-MIPS-select-CPU_MIPS64-for-remaining-MIPS64-CPUs.patch
commit 5a4fa44f5e1b in kernel, part of v5.13

Move them to backports folder to make maintainance easier.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>

3 files changed, 96 insertions, 0 deletions

diff --git a/target/linux/generic/backport-5.10/103-v5.13-MIPS-select-CPU_MIPS64-for-remaining-MIPS64-CPUs.patch b/target/linux/generic/backport-5.10/103-v5.13-MIPS-select-CPU_MIPS64-for-remaining-MIPS64-CPUs.patch
new file mode 100644
index 0000000000..cf79e9a449
--- /dev/null
+++ b/target/linux/generic/backport-5.10/103-v5.13-MIPS-select-CPU_MIPS64-for-remaining-MIPS64-CPUs.patch
@@ -0,0 +1,36 @@
+From 6523061868212473f63812a0c477a161742bed42 Mon Sep 17 00:00:00 2001
+From: "Jason A. Donenfeld" <Jason@zx2c4.com>
+Date: Sat, 27 Feb 2021 13:20:24 +0100
+Subject: [PATCH] MIPS: select CPU_MIPS64 for remaining MIPS64 CPUs
+
+The CPU_MIPS64 and CPU_MIPS32 variables are supposed to be able to
+distinguish broadly between 64-bit and 32-bit MIPS CPUs. However, they
+weren't selected by the specialty CPUs, Octeon and Loongson, which meant
+it was possible to hit a weird state of:
+
+    MIPS=y, CONFIG_64BIT=y, CPU_MIPS64=n
+
+This commit rectifies the issue by having CPU_MIPS64 be selected when
+the missing Octeon or Loongson models are selected.
+
+Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Cc: Ralf Baechle <ralf@linux-mips.org>
+Cc: George Cherian <gcherian@marvell.com>
+Cc: Huacai Chen <chenhuacai@kernel.org>
+Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
+Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
+---
+ arch/mips/Kconfig | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/mips/Kconfig
++++ b/arch/mips/Kconfig
+@@ -2075,7 +2075,7 @@ config CPU_MIPS32
+ config CPU_MIPS64
+ 	bool
+ 	default y if CPU_MIPS64_R1 || CPU_MIPS64_R2 || CPU_MIPS64_R5 || \
+-		     CPU_MIPS64_R6
++		     CPU_MIPS64_R6 || CPU_LOONGSON64 || CPU_CAVIUM_OCTEON
+ 
+ #
+ # These indicate the revision of the architecture
diff --git a/target/linux/generic/backport-5.10/311-v5.11-MIPS-zboot-put-appended-dtb-into-a-section.patch b/target/linux/generic/backport-5.10/311-v5.11-MIPS-zboot-put-appended-dtb-into-a-section.patch
new file mode 100644
index 0000000000..3f8808f702
--- /dev/null
+++ b/target/linux/generic/backport-5.10/311-v5.11-MIPS-zboot-put-appended-dtb-into-a-section.patch
@@ -0,0 +1,36 @@
+From 7d1531c81c0fb4c93bea8dc316043ad0e4d0c270 Mon Sep 17 00:00:00 2001
+From: Chuanhong Guo <gch981213@gmail.com>
+Date: Sun, 25 Oct 2020 23:19:40 +0800
+Subject: [PATCH] MIPS: zboot: put appended dtb into a section
+
+This will make a separated section for dtb appear in ELF, and we can
+then use objcopy to patch a dtb into vmlinuz when RAW_APPENDED_DTB
+is set in kernel config.
+
+command to patch a dtb:
+objcopy --set-section-flags=.appended_dtb=alloc,contents \
+        --update-section=.appended_dtb=<target>.dtb vmlinuz vmlinuz-dtb
+
+Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
+---
+ arch/mips/boot/compressed/ld.script | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+--- a/arch/mips/boot/compressed/ld.script
++++ b/arch/mips/boot/compressed/ld.script
+@@ -31,9 +31,12 @@ SECTIONS
+ 		CONSTRUCTORS
+ 		. = ALIGN(16);
+ 	}
+-	__appended_dtb = .;
+-	/* leave space for appended DTB */
+-	. += 0x100000;
++
++	.appended_dtb : {
++		__appended_dtb = .;
++		/* leave space for appended DTB */
++		. += 0x100000;
++	}
+ 
+ 	_edata = .;
+ 	/* End of data section */
diff --git a/target/linux/generic/backport-5.10/499-v5.13-mtd-don-t-lock-when-recursively-deleting-partitions.patch b/target/linux/generic/backport-5.10/499-v5.13-mtd-don-t-lock-when-recursively-deleting-partitions.patch
new file mode 100644
index 0000000000..d34248fbc7
--- /dev/null
+++ b/target/linux/generic/backport-5.10/499-v5.13-mtd-don-t-lock-when-recursively-deleting-partitions.patch
@@ -0,0 +1,24 @@
+From: David Bauer <mail@david-bauer.net>
+Date: Wed, 17 Feb 2021 03:21:39 +0100
+Subject: [PATCH] mtd: don't lock when recursively deleting partitions
+
+When recursively deleting partitions, don't acquire the masters
+partition lock twice. Otherwise the process endy up in a deadlocked
+state.
+
+Signed-off-by: David Bauer <mail@david-bauer.net>
+---
+ drivers/mtd/mtdpart.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mtd/mtdpart.c
++++ b/drivers/mtd/mtdpart.c
+@@ -331,7 +331,7 @@ static int __del_mtd_partitions(struct m
+ 
+ 	list_for_each_entry_safe(child, next, &mtd->partitions, part.node) {
+ 		if (mtd_has_partitions(child))
+-			del_mtd_partitions(child);
++			__del_mtd_partitions(child);
+ 
+ 		pr_info("Deleting %s MTD partition\n", child->name);
+ 		ret = del_mtd_device(child);