On Mon, Apr 8, 2019 at 9:54 AM Alexander Dahl <ada@xxxxxxxxxxx> wrote: > > >> You would have to extend leds-gpio bindings by some property defining > > >> forbidden states for given LED child node, i.e. which sub-LED cannot > > >> be turned on in the same time. If the forbidden state is going to be > > >> set, then just return -EBUSY from the brightness_set callback. > > >> leds-gpio driver would have to be altered for that too, to understand > > >> the new DT property. > > > > > > I'd really like to make it go into new (different) driver, as most > > > systems do not need that functionality. > > > > I wonder what Linus Walleij thinks. > > Personally I like the approach to have one LED with an additional attribute > 'color' better, it's easy to understand from the user side. The other proposal > to see two different LEDs and disallow certain settings if the other LED is in > the "wrong state" could lead to unexpected behaviour from the userspace point > of view. I agree with this point. I am one of the sinners. arch/arm/boot/dts/gemini-dlink-dir-685.dts Has two GPIO LEDs one red and one green, but they are one LED with two mutually exclusive colors just like the above. Ideally, the kernel needs to be aware that this is a single LED controlled by two GPIOs, so the LED can hold a state indicating one or the other color or OFF, and transitions from one color to the next or to off but not to both, as a state machine. BUT! You also need to be able to set triggers for each color, as for example in the above, ORANGE means write to disk and BLUE means read from disk. (Not my choice, the firmware from Dlink does this color scheme.) The current setup representing it as two LEDs and let chaos sort it out works reasonably well (and it's what the Dlink firmware does as well) but it'd be nice to get it under control to give a streamlined user experience. Yours, Linus Walleij
