Hi! > so I've been thinking a little about LED HW triggering API since Jacek > replied to my patch for Turris LEDs. > > There are many chips which expose SW control of LEDs which can also be > put into HW control mode, for example network PHYs, switches, wireless > cards etc. > > Jacek proposed a hardware_controlled file to the LED core, exposed only > if supported by hardware when the a new flag LED_DEV_CAP_HW_CONTROL is > set on the LED. ... > - if the device supports several hardware controlled modes, it is > put into one of these modes and a hardware_trigger file is > created, via which these mode can be changed. > This hardware_trigger file behaves similarly to classic trigger > file, ie. on read it returns space-separated list of supported > hardware triggers, the currently selected one in brackets. Ok, so it seems we need "hardware_trigger" (or "hw_trigger"?) file, anyway, because it is common for hardware to have few modes. What about getting rid of hardware_controlled file, and just having "hw_trigger", working similar to current "trigger" semantics? hw_trigger would * only be present if LED can be hardware controlled * echo none > hw_trigger would give control to software * echo mode > hw_trigger would give control to hardware, in given mode * cat hw_trigger would list possible modes. * echo 0 > brightness would clear set both "trigger" and "hw_trigger" to none. * any change to trigger or hw_trigger would set the other one to "none". But .. looking at proposal. I believe most consistent / logical solution would be to simply add hardware triggers into list of triggers, and treat them the same way. Yes, that would mean different trigger lists per LED, but I don't think that's a problem, and it is logical solution for our users. Best regards, 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
