tjh.dev
Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
leds: TODO: Add documentation about possible subsystem improvements
Help welcome :-).
Signed-off-by: Pavel Machek <pavel@ucw.cz>
+75
+75
drivers/leds/TODO
+75
drivers/leds/TODO
···
1
+
-*- org -*-
2
+
3
+
* On/off LEDs should have max_brightness of 1
4
+
* Get rid of enum led_brightness
5
+
6
+
It is really an integer, as maximum is configurable. Get rid of it, or
7
+
make it into typedef or something.
8
+
9
+
* Review atomicity requirements in LED subsystem
10
+
11
+
Calls that may and that may not block are mixed in same structure, and
12
+
semantics is sometimes non-intuitive. (For example blink callback may
13
+
not sleep.) Review the requirements for any bugs and document them
14
+
clearly.
15
+
16
+
* LED names are still a mess
17
+
18
+
No two LEDs have same name, so the names are probably unusable for the
19
+
userland. Nudge authors into creating common LED names for common
20
+
functionality.
21
+
22
+
? Perhaps check for known LED names during boot, and warn if there are
23
+
LEDs not on the list?
24
+
25
+
* Split drivers into subdirectories
26
+
27
+
The number of drivers is getting big, and driver for on/off LED on a
28
+
i/o port is really quite different from camera flash LED, which is
29
+
really different from driver for RGB color LED that can run its own
30
+
microcode. Split the drivers somehow.
31
+
32
+
* Figure out what to do with RGB leds
33
+
34
+
Multicolor is a bit too abstract. Yes, we can have
35
+
Green-Magenta-Ultraviolet LED, but so far all the LEDs we support are
36
+
RGB, and not even RGB-White or RGB-Yellow variants emerged.
37
+
38
+
Multicolor is not a good fit for RGB LED. It does not really know
39
+
about LED color. In particular, there's no way to make LED "white".
40
+
41
+
Userspace is interested in knowing "this LED can produce arbitrary
42
+
color", which not all multicolor LEDs can.
43
+
44
+
Proposal: let's add "rgb" to led_colors in drivers/leds/led-core.c,
45
+
add corresponding device tree defines, and use that, instead of
46
+
multicolor for RGB LEDs.
47
+
48
+
We really need to do that now; "white" stuff can wait.
49
+
50
+
RGB LEDs are quite common, and it would be good to be able to turn LED
51
+
white and to turn it into any arbitrary color. It is essential that
52
+
userspace is able to set arbitrary colors, and it might be good to
53
+
have that ability from kernel, too... to allow full-color triggers.
54
+
55
+
* Command line utility to manipulate the LEDs?
56
+
57
+
/sys interface is not really suitable to use by hand, should we have
58
+
an utility to perform LED control?
59
+
60
+
In particular, LED names are still a mess (see above) and utility
61
+
could help there by presenting both old and new names while we clean
62
+
them up.
63
+
64
+
In future, I'd like utility to accept both old and new names while we
65
+
clean them up.
66
+
67
+
It would be also nice to have useful listing mode -- name, type,
68
+
current brightness/trigger...
69
+
70
+
In future, it would be good to be able to set rgb led to particular
71
+
color.
72
+
73
+
And probably user-friendly interface to access LEDs for particular
74
+
ethernet interface would be nice.
75
+