summaryrefslogtreecommitdiff
path: root/drivers/leds/trigger
diff options
context:
space:
mode:
authorLinus Walleij <linus.walleij@linaro.org>2023-03-14 22:00:59 +0100
committerLee Jones <lee@kernel.org>2023-03-16 15:08:44 +0000
commit8f0adae1cb1a3cf83e38dd435831baa38dd84b4c (patch)
tree1be1e6da4fd3bac0fd0786bf6c240c73b5d3d9bf /drivers/leds/trigger
parente0248a258c7f5f7b0a3f2283f5cd2e472dfb7eeb (diff)
leds: Mark GPIO LED trigger broken
The GPIO LED trigger exposes a userspace ABI where a user can echo a GPIO number from the global GPIO numberspace into a file that will trigger a certain LED when active. This is problematic because the global GPIO numberspace is inherently instable. The trigger came about at a time when systems had one GPIO controller that defined hard-wired GPIOs numbered 0..N and this number space was stable. We have since moved to dynamic allocation of GPIO numbers and there is no real guarantee that a GPIO number will stay consistent even across a reboot: consider a USB attached GPIO controller for example. Or two. Or the effect of probe order after adding -EPROBE_DEFER to the kernel. The trigger was added to support keypad LEDs on the Nokia n810 from the GPIO event when a user slides up/down the keypad. This is arch/arm/boot/dts/omap2420-n810.dts. A userspace script is needed to activate the trigger. This will be broken unless the script was updated recently since the OMAP GPIO controller now uses dynamic GPIO number allocations. I want to know that this trigger has active users that cannot live without it if we are to continue to support it. Option if this is really needed: I can develop a new trigger that can associate GPIOs with LEDs as triggers using device tree, which should also remove the use of userspace custom scripts to achieve this and be much more trustworthy, if someone with the Nokia n810 or a device with a similar need is willing to test it. Suggested-by Pavel Machek <pavel@ucw.cz> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230314210059.419159-1-linus.walleij@linaro.org
Diffstat (limited to 'drivers/leds/trigger')
-rw-r--r--drivers/leds/trigger/Kconfig1
1 files changed, 1 insertions, 0 deletions
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index dc6816d36d06..2a57328eca20 100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -83,6 +83,7 @@ config LEDS_TRIGGER_ACTIVITY
config LEDS_TRIGGER_GPIO
tristate "LED GPIO Trigger"
depends on GPIOLIB || COMPILE_TEST
+ depends on BROKEN
help
This allows LEDs to be controlled by gpio events. It's good
when using gpios as switches and triggering the needed LEDs