> >               link3 { 
> >                       function = LED_FUNCTION_RSSI; 
> >                       color = <LED_COLOR_ID_GREEN>; 
> >                       gpios = <&gpio 15 GPIO_ACTIVE_LOW>; 
> >               }; 
> >       }; 
> Well, this is not really three LEDs. This is more like... LED meter 
> composed of three LEDs. And we don't have good support for that. 
> But I guess we'll need it one day. There were some previous attempts: 
> https://lwn.net/Articles/802967/ 
> Do you plan to control RSSI LEDs from kernel? 

To be honest, I mostly sent this patch for completeness.

OpenWrt uses a very simple process written in C for updating these LEDs, which is quite old and has essentially remained unchanged for years, but does its job.
I personally don't think there will be overwhelming interest in touching this and migrate it to whatever different implementation without a pressing need.

My main interest here was/is that I started to evaluate how OpenWrt can migrate from LED labels to the "new" color/function syntax and to me the rssi leds are a dedicated type that should be supported.
So I fear I won't be helpful for the implementation of RSSI leds in the kernel in general.

For the three leds vs. set of leds discussion: Note that we are interested in (and already do) exposing each LED to the user individually (in user-space via sysfs), so the user can redefine the purpose of the LED freely based on his/her desire. Therefore, a total abstraction of the set of LEDs as a single entity would be detrimental for us here.

Best

Adrian