Hi Marek, On 3/20/20 8:43 PM, Marek Behun wrote: > 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 OK, that seems like a decent justification. If you had provided it at that time then maybe we would have had generic hw trigger mechanism merged a year ago :-). -- Best regards, Jacek Anaszewski
