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. ...and it is going to be "fun" with triggers. I'd just call the hardware "broken", but not expose that to the userspace... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
