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

[Takashi Iwai <tiwai@xxxxxxx>]

On Tue, 05 Mar 2024 10:55:39 +0100,
Lee Jones wrote:
> 
> 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.

Or merging via input tree?
The changes are relatively small and easy, after all.


thanks,

Takashi