On 15.02.2024 13:29, Takashi Iwai wrote: > On Tue, 13 Feb 2024 08:30:30 +0100, > Heiner Kallweit wrote: >> >> If a simple trigger is assigned to a LED, then the LED may be off until >> the next led_trigger_event() call. This may be an issue for simple >> triggers with rare led_trigger_event() calls, e.g. power supply >> charging indicators (drivers/power/supply/power_supply_leds.c). >> Therefore persist the brightness value of the last led_trigger_event() >> call and use this value if the trigger is assigned to a LED. >> This change allows to use simple triggers in more cases. >> As a first use case simplify handling of the mute audio trigger. >> >> This series touches few subsystems. I'd propose to handle it via >> the LED subsystem. >> >> Heiner Kallweit (4): >> leds: trigger: Store brightness set by led_trigger_event() >> ALSA: control-led: Integrate mute led trigger >> Input: leds: Prepare for removal of config option LEDS_AUDIO_TRIGGER >> leds: trigger: audio: Remove this trigger > > LGTM. > > Reviewed-by: Takashi Iwai <tiwai@xxxxxxx> > > One thing I'm not 100% sure is the movement from ledtrig:audio-mute > and ledtrig:audio-micmute alias into snd-ctl-led module. Who would > use/process those aliases? I don't think this would be a problem, but > it might change the loading order. > The ledtrig:% aliases are used when a LED device is registered that has a default trigger. Like in the case here with the input leds (patch 3). There might also be DT-defined LEDs with a audio mute default trigger. snd-ctl-led has a dependency on snd, so at least wrt snd the load order doesn't change. > > Thanks! > > Takashi Heiner
