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