Re: [PATCH 0/4] leds: trigger: Improve handling of led_trigger_event() and simplify mute audio trigger

[Lee Jones <lee@xxxxxxxxxx>]

On Sat, 02 Mar 2024, Heiner Kallweit wrote:

> On 29.02.2024 18:26, Lee Jones wrote:
> > On Tue, 13 Feb 2024, 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
> >>
> >>  arch/mips/configs/ci20_defconfig     |  1 -
> > 
> >>  drivers/input/input-leds.c           |  8 +---
> > 
> > This does not apply.
> > 
> > Please rebase onto v6.8-rc1.
> > 
> Since v6.8-rc1 the following has been added, which is touched by
> my series:
> 698b43780ba2 ("Input: leds - set default-trigger for mute")
> 
> Rebasing onto v6.8-rc1 would mean:
> - remove the change to input-leds from the series
> - resubmit this change via input subsystem
> 
> This would affect bisectability, because for the time being
> input-leds would reference a config symbol that doesn't exist
> any longer.
> 
> We'd be fine only if the change to input-leds is applied first.
> I think that's the best way to go, if you can't accept a series
> based on linux-next.

Then it's going to have to wait until v6.10.

-- 
Lee Jones [李琼斯]