Orange Pi5 kernel

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