On 07/09/2018 10:28 AM, Pavel Machek wrote:
Hi!
Thank you for the explanation. I tried to look at the problem from
the LED state side, and got the following truth table:
(L0,L1 - LED class devices' brightness states,
state values: on=1, off=0)
L0 L1 XY
0 0 11
1 0 10
1 1 -- (return -EBUSY on attempt of setting)
0 1 01
"--" signifies here the forbidden state. Since L0=0 L1=1 has
two possible XY combinations (01 and 00), then only one of them
is shown in this table, and the other one won't need to be ever
set.
Ok, so EBUSY after all. I had the same idea but was afraid users of the
LEDs would not really be prepared to handle errors. At the first glance
i failed to find examples of setters returning errors. And the higher
level abstractions are "void" again.
EBUSY seems pointless. Even the sysfs interface does not let you know
about it.
Ah, indeed, this is annoying drawback of brightness_set() op.
...and it is going to be "fun" with triggers.
I'd just call the hardware "broken", but not expose that to the
userspace...
OK, but we'll need good documentation in Documentation/leds.
--
Best regards,
Jacek Anaszewski
