On Tue, 14 Mar 2023, Linus Walleij wrote: > 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. > > Cc: Arnd Bergmann <arnd@xxxxxxxx> > Cc: Tony Lindgren <tony@xxxxxxxxxxx> > Cc: Felipe Balbi <balbi@xxxxxxxxxx> > Cc: linux-omap@xxxxxxxxxxxxxxx > Cc: linux-gpio@xxxxxxxxxxxxxxx > > Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxx> > --- > ChangeLog v1->v2: > - Be less intrusive and just mark the feature broken > for now. > --- > drivers/leds/trigger/Kconfig | 1 + > 1 file changed, 1 insertion(+) Added Pavel's Suggested-by: Applied, thanks -- Lee Jones [李琼斯]
