diff options
author | Pavel Machek <pavel@ucw.cz> | 2020-09-25 11:29:17 +0200 |
---|---|---|
committer | Pavel Machek <pavel@ucw.cz> | 2020-09-30 19:15:33 +0200 |
commit | 364682d1bc16277b67f31e411a00e13c50002d2e (patch) | |
tree | 7b499b4628b5dd219c83535c059b2c611252aff9 /drivers | |
parent | 7ac5338c3c7c849729f629b6a35d88ac3d43cc56 (diff) | |
download | linux-stable-364682d1bc16277b67f31e411a00e13c50002d2e.tar.gz linux-stable-364682d1bc16277b67f31e411a00e13c50002d2e.tar.bz2 linux-stable-364682d1bc16277b67f31e411a00e13c50002d2e.zip |
leds: TODO: Add documentation about possible subsystem improvements
Help welcome :-).
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Diffstat (limited to 'drivers')
-rw-r--r-- | drivers/leds/TODO | 75 |
1 files changed, 75 insertions, 0 deletions
diff --git a/drivers/leds/TODO b/drivers/leds/TODO new file mode 100644 index 000000000000..bfa60fa1d812 --- /dev/null +++ b/drivers/leds/TODO @@ -0,0 +1,75 @@ +-*- org -*- + +* On/off LEDs should have max_brightness of 1 +* Get rid of enum led_brightness + +It is really an integer, as maximum is configurable. Get rid of it, or +make it into typedef or something. + +* Review atomicity requirements in LED subsystem + +Calls that may and that may not block are mixed in same structure, and +semantics is sometimes non-intuitive. (For example blink callback may +not sleep.) Review the requirements for any bugs and document them +clearly. + +* LED names are still a mess + +No two LEDs have same name, so the names are probably unusable for the +userland. Nudge authors into creating common LED names for common +functionality. + +? Perhaps check for known LED names during boot, and warn if there are +LEDs not on the list? + +* Split drivers into subdirectories + +The number of drivers is getting big, and driver for on/off LED on a +i/o port is really quite different from camera flash LED, which is +really different from driver for RGB color LED that can run its own +microcode. Split the drivers somehow. + +* Figure out what to do with RGB leds + +Multicolor is a bit too abstract. Yes, we can have +Green-Magenta-Ultraviolet LED, but so far all the LEDs we support are +RGB, and not even RGB-White or RGB-Yellow variants emerged. + +Multicolor is not a good fit for RGB LED. It does not really know +about LED color. In particular, there's no way to make LED "white". + +Userspace is interested in knowing "this LED can produce arbitrary +color", which not all multicolor LEDs can. + + Proposal: let's add "rgb" to led_colors in drivers/leds/led-core.c, + add corresponding device tree defines, and use that, instead of + multicolor for RGB LEDs. + + We really need to do that now; "white" stuff can wait. + +RGB LEDs are quite common, and it would be good to be able to turn LED +white and to turn it into any arbitrary color. It is essential that +userspace is able to set arbitrary colors, and it might be good to +have that ability from kernel, too... to allow full-color triggers. + +* Command line utility to manipulate the LEDs? + +/sys interface is not really suitable to use by hand, should we have +an utility to perform LED control? + +In particular, LED names are still a mess (see above) and utility +could help there by presenting both old and new names while we clean +them up. + +In future, I'd like utility to accept both old and new names while we +clean them up. + +It would be also nice to have useful listing mode -- name, type, +current brightness/trigger... + +In future, it would be good to be able to set rgb led to particular +color. + +And probably user-friendly interface to access LEDs for particular +ethernet interface would be nice. + |