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 [李琼斯]
