mbox series

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

Message ID 30d49088-283c-40f3-b97b-fd5f5174a467@gmail.com (mailing list archive)
Headers show
Series leds: trigger: Improve handling of led_trigger_event() and simplify mute audio trigger | expand

Message

Heiner Kallweit Feb. 13, 2024, 7:30 a.m. UTC
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 +---
 drivers/leds/led-triggers.c          |  6 ++-
 drivers/leds/trigger/Kconfig         |  7 ---
 drivers/leds/trigger/Makefile        |  1 -
 drivers/leds/trigger/ledtrig-audio.c | 67 ----------------------------
 include/linux/leds.h                 | 29 ++++++------
 sound/core/Kconfig                   |  1 -
 sound/core/control_led.c             | 20 +++++++--
 9 files changed, 37 insertions(+), 103 deletions(-)
 delete mode 100644 drivers/leds/trigger/ledtrig-audio.c

Comments

Takashi Iwai Feb. 15, 2024, 12:29 p.m. UTC | #1
On Tue, 13 Feb 2024 08:30:30 +0100,
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

LGTM.

Reviewed-by: Takashi Iwai <tiwai@suse.de>

One thing I'm not 100% sure is the movement from ledtrig:audio-mute
and ledtrig:audio-micmute alias into snd-ctl-led module.  Who would
use/process those aliases?  I don't think this would be a problem, but
it might change the loading order.


Thanks!

Takashi
Heiner Kallweit Feb. 16, 2024, 12:18 p.m. UTC | #2
On 15.02.2024 13:29, Takashi Iwai wrote:
> On Tue, 13 Feb 2024 08:30:30 +0100,
> 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
> 
> LGTM.
> 
> Reviewed-by: Takashi Iwai <tiwai@suse.de>
> 
> One thing I'm not 100% sure is the movement from ledtrig:audio-mute
> and ledtrig:audio-micmute alias into snd-ctl-led module.  Who would
> use/process those aliases?  I don't think this would be a problem, but
> it might change the loading order.
> 
The ledtrig:% aliases are used when a LED device is registered that has
a default trigger. Like in the case here with the input leds (patch 3).
There might also be DT-defined LEDs with a audio mute default trigger.
snd-ctl-led has a dependency on snd, so at least wrt snd the load order
doesn't change.

> 
> Thanks!
> 
> Takashi

Heiner
Lee Jones Feb. 23, 2024, 3:45 p.m. UTC | #3
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 +---
>  drivers/leds/led-triggers.c          |  6 ++-
>  drivers/leds/trigger/Kconfig         |  7 ---
>  drivers/leds/trigger/Makefile        |  1 -
>  drivers/leds/trigger/ledtrig-audio.c | 67 ----------------------------
>  include/linux/leds.h                 | 29 ++++++------
>  sound/core/Kconfig                   |  1 -
>  sound/core/control_led.c             | 20 +++++++--
>  9 files changed, 37 insertions(+), 103 deletions(-)
>  delete mode 100644 drivers/leds/trigger/ledtrig-audio.c

Are the sound maintainers on-board with this?
Takashi Iwai Feb. 23, 2024, 3:47 p.m. UTC | #4
On Fri, 23 Feb 2024 16:45:59 +0100,
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 +---
> >  drivers/leds/led-triggers.c          |  6 ++-
> >  drivers/leds/trigger/Kconfig         |  7 ---
> >  drivers/leds/trigger/Makefile        |  1 -
> >  drivers/leds/trigger/ledtrig-audio.c | 67 ----------------------------
> >  include/linux/leds.h                 | 29 ++++++------
> >  sound/core/Kconfig                   |  1 -
> >  sound/core/control_led.c             | 20 +++++++--
> >  9 files changed, 37 insertions(+), 103 deletions(-)
> >  delete mode 100644 drivers/leds/trigger/ledtrig-audio.c
> 
> Are the sound maintainers on-board with this?

See
  https://lore.kernel.org/r/87zfw1ewrd.wl-tiwai@suse.de


thanks,

Takashi
Lee Jones Feb. 23, 2024, 4:04 p.m. UTC | #5
On Fri, 23 Feb 2024, Takashi Iwai wrote:

> On Fri, 23 Feb 2024 16:45:59 +0100,
> 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 +---
> > >  drivers/leds/led-triggers.c          |  6 ++-
> > >  drivers/leds/trigger/Kconfig         |  7 ---
> > >  drivers/leds/trigger/Makefile        |  1 -
> > >  drivers/leds/trigger/ledtrig-audio.c | 67 ----------------------------
> > >  include/linux/leds.h                 | 29 ++++++------
> > >  sound/core/Kconfig                   |  1 -
> > >  sound/core/control_led.c             | 20 +++++++--
> > >  9 files changed, 37 insertions(+), 103 deletions(-)
> > >  delete mode 100644 drivers/leds/trigger/ledtrig-audio.c
> > 
> > Are the sound maintainers on-board with this?
> 
> See
>   https://lore.kernel.org/r/87zfw1ewrd.wl-tiwai@suse.de

Were you happy with Heiner's response?
Lee Jones Feb. 23, 2024, 4:05 p.m. UTC | #6
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

Dmitry, you happy too?

>   leds: trigger: audio: Remove this trigger
> 
>  arch/mips/configs/ci20_defconfig     |  1 -
>  drivers/input/input-leds.c           |  8 +---
>  drivers/leds/led-triggers.c          |  6 ++-
>  drivers/leds/trigger/Kconfig         |  7 ---
>  drivers/leds/trigger/Makefile        |  1 -
>  drivers/leds/trigger/ledtrig-audio.c | 67 ----------------------------
>  include/linux/leds.h                 | 29 ++++++------
>  sound/core/Kconfig                   |  1 -
>  sound/core/control_led.c             | 20 +++++++--
>  9 files changed, 37 insertions(+), 103 deletions(-)
>  delete mode 100644 drivers/leds/trigger/ledtrig-audio.c
> 
> -- 
> 2.43.1
>
Takashi Iwai Feb. 23, 2024, 4:05 p.m. UTC | #7
On Fri, 23 Feb 2024 17:04:15 +0100,
Lee Jones wrote:
> 
> On Fri, 23 Feb 2024, Takashi Iwai wrote:
> 
> > On Fri, 23 Feb 2024 16:45:59 +0100,
> > 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 +---
> > > >  drivers/leds/led-triggers.c          |  6 ++-
> > > >  drivers/leds/trigger/Kconfig         |  7 ---
> > > >  drivers/leds/trigger/Makefile        |  1 -
> > > >  drivers/leds/trigger/ledtrig-audio.c | 67 ----------------------------
> > > >  include/linux/leds.h                 | 29 ++++++------
> > > >  sound/core/Kconfig                   |  1 -
> > > >  sound/core/control_led.c             | 20 +++++++--
> > > >  9 files changed, 37 insertions(+), 103 deletions(-)
> > > >  delete mode 100644 drivers/leds/trigger/ledtrig-audio.c
> > > 
> > > Are the sound maintainers on-board with this?
> > 
> > See
> >   https://lore.kernel.org/r/87zfw1ewrd.wl-tiwai@suse.de
> 
> Were you happy with Heiner's response?

Yes.


Takashi
Lee Jones Feb. 29, 2024, 5:26 p.m. UTC | #8
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.

>  drivers/leds/led-triggers.c          |  6 ++-
>  drivers/leds/trigger/Kconfig         |  7 ---
>  drivers/leds/trigger/Makefile        |  1 -
>  drivers/leds/trigger/ledtrig-audio.c | 67 ----------------------------
>  include/linux/leds.h                 | 29 ++++++------
>  sound/core/Kconfig                   |  1 -
>  sound/core/control_led.c             | 20 +++++++--
>  9 files changed, 37 insertions(+), 103 deletions(-)
>  delete mode 100644 drivers/leds/trigger/ledtrig-audio.c
> 
> -- 
> 2.43.1
>
Heiner Kallweit March 2, 2024, 3:09 p.m. UTC | #9
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.

>>  drivers/leds/led-triggers.c          |  6 ++-
>>  drivers/leds/trigger/Kconfig         |  7 ---
>>  drivers/leds/trigger/Makefile        |  1 -
>>  drivers/leds/trigger/ledtrig-audio.c | 67 ----------------------------
>>  include/linux/leds.h                 | 29 ++++++------
>>  sound/core/Kconfig                   |  1 -
>>  sound/core/control_led.c             | 20 +++++++--
>>  9 files changed, 37 insertions(+), 103 deletions(-)
>>  delete mode 100644 drivers/leds/trigger/ledtrig-audio.c
>>
>> -- 
>> 2.43.1
>>
>
Lee Jones March 5, 2024, 9:55 a.m. UTC | #10
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.
Takashi Iwai March 5, 2024, 10:26 a.m. UTC | #11
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
Lee Jones March 5, 2024, 10:40 a.m. UTC | #12
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 March 5, 2024, 12:08 p.m. UTC | #13
On Tue, 13 Feb 2024 08:30:30 +0100, 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.
> 
> [...]

Applied, thanks!

[1/4] leds: trigger: Store brightness set by led_trigger_event()
      commit: 575129855dee0e364af7df84a77ab5cca54b1442
[2/4] ALSA: control-led: Integrate mute led trigger
      commit: ba8adb1646ee498029ac12b20e792d9d0dd17920
[3/4] Input: leds: Prepare for removal of config option LEDS_AUDIO_TRIGGER
      (no commit info)
[4/4] leds: trigger: audio: Remove this trigger
      (no commit info)

--
Lee Jones [李琼斯]