Hei hei, thanks for your proposals, comments below. (Disclaimer: up to now I am only user of the LED subsystem from userspace, mostly just configuring gpio-leds in DT and setting triggers for already working LEDs.) Am Mittwoch, 3. April 2019, 21:55:21 CEST schrieb Jacek Anaszewski: > On 4/2/19 11:31 PM, Pavel Machek wrote: > > On Tue 2019-04-02 22:52:29, Jacek Anaszewski 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 just ordered some additional hardware for easy breadboard-testing with another board (I can't take the real target board with me), I hope I find some time this year to send some RFC patches. If you have additional ideas or comments on this, I'm open for any suggestions. Greets Alex
