Hi Jacek, I want to open the discussions about HW LED triggers again. The last time (which was almost a year ago, sorry for that) I proposed an API which used the same sysfs trigger file as for regular trigger setting, but the HW triggers were prefixed with "hw:" (and each LED classdev can have different ones). You wrote: > I wonder what will be the gain of having hw triggers incorporated > into LED trigger mechanism, if they are meant not be generic > by design? Only the LED class driver exposing a hw trigger > will know how to set it up, and will define protocol via which > the settings will be passed from sysfs to the trigger (const char* > parameter in the hw_trigger_set() op). > > And it has to be that way because hardware triggers are hardware > specific. LED class driver will have to create trigger specific > sysfs files regardless of whether they are to be shown on > trigger avtivation, or will persist for the whole LED class device > lifetime. > > Maybe I'm missing some vital details from the previous discussions, > but this is what's come to my mind now, after analyzing the proposed > design. > > The question is: what problem we solve by exposing non-generic > hw trigger, whose implementation will be in the driver anyway, > instead of just bypassing the trigger mechanism and exposing > the required interface directly? I would still like to go this way, so my answer to this questions is: - IMO this is simpler for users and existing scripts - the idea is that it should no be possible to set a software trigger and a hardware trigger at the same time (this would just end up in more complications), and introducing special hw_trigger file or something could make users think that you can Marek
