kernel: bump 5.4 to 5.4.142

Removed upstreamed:
  hack-5.4/991-platform-x86-pcengines-apuv2-revert-simswitch.patch

All other patches automatically rebased.

Build system: x86_64
Build-tested: ipq806x/R7800
Run-tested: ipq806x/R7800

No dmesg regressions, everything functional

Signed-off-by: John Audia <graysky@archlinux.us>

2 files changed, 1 insertions, 57 deletions

diff --git a/target/linux/generic/hack-5.4/221-module_exports.patch b/target/linux/generic/hack-5.4/221-module_exports.patch
index 0f7840b8d8..47f40ac5e1 100644
--- a/target/linux/generic/hack-5.4/221-module_exports.patch
+++ b/target/linux/generic/hack-5.4/221-module_exports.patch
@@ -56,7 +56,7 @@ Signed-off-by: Felix Fietkau <nbd@nbd.name>
  	}								\
  									\
  	/* __*init sections */						\
-@@ -904,6 +914,8 @@
+@@ -905,6 +915,8 @@
  	EXIT_TEXT							\
  	EXIT_DATA							\
  	EXIT_CALL							\
diff --git a/target/linux/generic/hack-5.4/991-platform-x86-pcengines-apuv2-revert-simswitch.patch b/target/linux/generic/hack-5.4/991-platform-x86-pcengines-apuv2-revert-simswitch.patch
deleted file mode 100644
index 84a4191157..0000000000
--- a/target/linux/generic/hack-5.4/991-platform-x86-pcengines-apuv2-revert-simswitch.patch
+++ /dev/null
@@ -1,56 +0,0 @@
-From 8c9254d41881c81bea610193c6ac59c8cb8b79fe Mon Sep 17 00:00:00 2001
-From: Florian Eckert <fe@dev.tdt.de>
-Date: Fri, 27 Mar 2020 16:11:55 +0100
-Subject: [PATCH] Revert "platform/x86: pcengines-apuv2: wire up simswitch gpio
- as led"
-
-This reverts commit 5037d4ddda31c2dbbb018109655f61054b1756dc.
-
-Commit message from linux:
-The APU3+ boards have two SIM sockets, while only one of them
-can be routed to the mpcie slots at a time. Selection is done
-via simswap gpio.
-
-We currently don't have a fitting subsystem for those cases yet,
-so just wire it up to a LED for the time being. While this isn't
-really semantically correct, it's a good compromise.
-
-Explanation why this does not work:
-This change connects the simswap to the LED subsystem of the kernel.
-From my point of view, it's nonsense. If we do it this way, then this
-can be switched relatively easily via the LED subsystem (trigger:
-none/default-on) and that is dangerous! If this is used, it would be
-unfavorable, since there is also another trigger (trigger: heartbeat/netdev).
-This LED also appears in the LuCI and can therefore be switched by the user.
-
-Therefore, this simswap GPIO should remain in the GPIO
-subsystem and be switched via it and not be connected to the LED
-subsystem. To avoid the problems mentioned above. The LED subsystem is
-not made for this and it is not a good compromise, but rather dangerous.
-
-Signed-off-by: Florian Eckert <fe@dev.tdt.de>
----
- drivers/platform/x86/pcengines-apuv2.c | 5 +----
- 1 file changed, 1 insertion(+), 4 deletions(-)
-
---- a/drivers/platform/x86/pcengines-apuv2.c
-+++ b/drivers/platform/x86/pcengines-apuv2.c
-@@ -77,8 +77,7 @@ static const struct amd_fch_gpio_pdata b
- static const struct gpio_led apu2_leds[] = {
- 	{ .name = "apu:green:1" },
- 	{ .name = "apu:green:2" },
--	{ .name = "apu:green:3" },
--	{ .name = "apu:simswap" },
-+	{ .name = "apu:green:3" }
- };
- 
- static const struct gpio_led_platform_data apu2_leds_pdata = {
-@@ -95,8 +94,6 @@ static struct gpiod_lookup_table gpios_l
- 				NULL, 1, GPIO_ACTIVE_LOW),
- 		GPIO_LOOKUP_IDX(AMD_FCH_GPIO_DRIVER_NAME, APU2_GPIO_LINE_LED3,
- 				NULL, 2, GPIO_ACTIVE_LOW),
--		GPIO_LOOKUP_IDX(AMD_FCH_GPIO_DRIVER_NAME, APU2_GPIO_LINE_SIMSWAP,
--				NULL, 3, GPIO_ACTIVE_LOW),
- 	}
- };
-