Multi-led configuration in dts

Andrew Jeffery andrew at aj.id.au
Tue Apr 26 15:12:05 AEST 2022



On Thu, 24 Mar 2022, at 23:26, sri d wrote:
> Hi Team,
>
> I am working on implementing Power and system identification LEDs, in 
> which
> LEDs are connected to GPIO pins directly. I need to handle two colors 
> (blue
> & yellow) for LEDs in *.dts file.
> In phosphor-led-sysfs repo, whether multi-led configuration is handled ?
> https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml

I did a quick grep in phosphor-led-sysfs and there's no support for the 
multicolor sysfs attributes that I saw.

>
> As far as I analyzed, multi-led seems to work for dedicated LED controllers
> and not for GPIO pins directly. Is there a way we can make it work for
> directly connected GPIOs ?
> https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.9-Multi-Color-LEDs

I'm not sure whether this should be handled in the kernel or in 
userspace. From a conceptual standpoint (and from some background 
discussion with Patrick) it sounds like you're using two LEDs as one, 
operating with a small, well-defined set of states across the two. It 
feels like it would be nice if this was exposed to userspace as a 
single thing, though whether that's an LED or not is another matter.

The alternative is to come up with some way to identify pairs of LEDs 
via the devicetree (the obvious, cheap-and-nasty approach is to use 
pairs of LED names) and do the work in userspace.

I don't know which is better (maybe someone should write a design 
document analysing the trade-offs?) but it would get kind of awkward 
with the current phosphor-led-sysfs design which exposes one process 
per LED. This doesn't give you much (any) abstraction in terms of the 
DBus objects/interfaces involved. I think it would be nice if we had 
something a bit more coherent for this specific use case. Something to 
consider is reworking phosphor-led-sysfs such that it exposes all the 
LEDs in a single process (but is still dynamic and driven by udev under 
the covers - e.g. make the udev rule do DBus calls to poke the one 
phosphor-led-sysfs instance). From there you can handle the pairing 
internally and expose a coherent interface that drives both LEDs once 
both are found by userspace.

Andrew


More information about the openbmc mailing list