HW LED triggers again

[Marek Behun <marek.behun@nic.cz>]

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