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

[Lee Jones <lee@xxxxxxxxxx>]

On Tue, 05 Mar 2024, Takashi Iwai wrote:

> 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.

That's likely to culminate in similar merge-conflicts when further
changes are made to:

  drivers/leds/led-triggers.c
  drivers/leds/trigger/Kconfig
  drivers/leds/trigger/Makefile
  drivers/leds/trigger/ledtrig-audio.c
  include/linux/leds.h

What happens if I take all but the Input change?  If this doesn't cause
build-failures and the Input change will definitely land in v6.9, it
could work.

-- 
Lee Jones [李琼斯]