Hi! > 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. So... what? If your system is one of those with single GPIO controller, you can still use it. If you have modern "complex" system, your userspace can find out desired GPIO number and then use it. > Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxx> > --- > drivers/leds/trigger/ledtrig-gpio.c | 202 ---------------------------- No. :-). You'd need to delete it from Kconfig/Makefile, too. But this is not how we handle deletions. Likely noone will miss this trigger, but correct way is to mark it as deprecated / broken in Kconfig, first, and see who screams. Best regards, Pavel -- People of Russia, stop Putin before his war on Ukraine escalates.
Attachment:
signature.asc
Description: PGP signature
