| -*- 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. | 
 |  |