target/hack-5.4: platform/x86/pcengines: revert led simswich compromise
authorFlorian Eckert <fe@dev.tdt.de>
Fri, 27 Mar 2020 15:23:14 +0000 (16:23 +0100)
committerHauke Mehrtens <hauke@hauke-m.de>
Fri, 26 Jun 2020 18:54:53 +0000 (20:54 +0200)
With this change the LED subsystem is abused in the kernel to switch the
simswap. This change will be reverted, so we could use again the gpio
subsystem.

Signed-off-by: Florian Eckert <fe@dev.tdt.de>
target/linux/generic/hack-5.4/991-platform-x86-pcengines-apuv2-revert-simswitch.patch [new file with mode: 0644]

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
new file mode 100644 (file)
index 0000000..84a4191
--- /dev/null
@@ -0,0 +1,56 @@
+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),
+       }
+ };