On 03/29/2018 09:06 PM, Pavel Machek wrote: > Hi! > >>> No, they are not. >>> >>> Example might be... wifi card. It has a led that can be either driven >>> by software, or show some hardware state that is not easily available >>> outside the card (think "collision on wireless channel"). >> >> But those hardware originated sources of LED events don't fall under >> LED Trigger definition, which is "kernel based source of LED events", >> since they alter LED state without kernel mediation AFAIU. What follows, >> they don't have related LED Trigger representation. > > So.. how do you propose to handle such hardware? Triggers seem to be > very reasonable way of doing that. > > And I believe we already have such triggers in-tree. Please spot one, so that we had some exemplary case for discussion. I'm not sure if I'm getting right what you mean. If I grep for led_trigger_register I can find drivers registering custom triggers with led_trigger_register_simple(). Nothing prevents any LED for registering for such trigger events, so why they couldn't be listed in a one common place? Trigger name clash is also not a risk since led_trigger_register() fails if trigger name is already in use. -- Best regards, Jacek Anaszewski
