Re: [PATCH 3/4] Input: leds: Prepare for removal of config option LEDS_AUDIO_TRIGGER

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Sat, Feb 24, 2024 at 10:31:17AM +0100, Heiner Kallweit wrote:
> On 24.02.2024 00:23, Dmitry Torokhov wrote:
> > On Tue, Feb 13, 2024 at 08:33:24AM +0100, Heiner Kallweit wrote:
> >> In a follow-up patch handling of the LED audio trigger will be changed,
> >> including removal of config symbol LEDS_AUDIO_TRIGGER. Therefore set
> >> the default trigger unconditionally to "audio-mute". It does no harm
> >> if a default trigger doesn't exist.
> >>
> >> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> >> ---
> >>  drivers/input/input-leds.c | 8 +-------
> >>  1 file changed, 1 insertion(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/input/input-leds.c b/drivers/input/input-leds.c
> >> index b16fc8194..176f1da7f 100644
> >> --- a/drivers/input/input-leds.c
> >> +++ b/drivers/input/input-leds.c
> >> @@ -18,12 +18,6 @@
> >>  #define VT_TRIGGER(_name)	.trigger = NULL
> >>  #endif
> >>  
> >> -#if IS_ENABLED(CONFIG_LEDS_TRIGGER_AUDIO)
> > 
> > Should it be simply changed to CONFIG_SND_CTL_LED?
> > 
> This would be another option. What is better IMO is a matter of
> personal taste. Setting the default trigger unconditionally may
> cause a negligible runtime overhead when the LED is instantiated,
> on the other hand it results in less code to be maintained.
> Do you have a preference?

I am less concerned about overhead than setting a non-existent default
trigger if the functionality is disabled. I would prefer having the
#ifdef.

Thanks.

-- 
Dmitry