76 lines
2.6 KiB
Plaintext
76 lines
2.6 KiB
Plaintext
|
-*- 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.
|
||
|
|
|