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@xxxxxxxxx>
>> ---
>> 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?
>> -#define AUDIO_TRIGGER(_name) .trigger = _name
>> -#else
>> -#define AUDIO_TRIGGER(_name) .trigger = NULL
>> -#endif
>> -
>> static const struct {
>> const char *name;
>> const char *trigger;
>> @@ -35,7 +29,7 @@ static const struct {
>> [LED_KANA] = { "kana", VT_TRIGGER("kbd-kanalock") },
>> [LED_SLEEP] = { "sleep" } ,
>> [LED_SUSPEND] = { "suspend" },
>> - [LED_MUTE] = { "mute", AUDIO_TRIGGER("audio-mute") },
>> + [LED_MUTE] = { "mute", "audio-mute" },
>> [LED_MISC] = { "misc" },
>> [LED_MAIL] = { "mail" },
>> [LED_CHARGING] = { "charging" },
>> --
>> 2.43.1
>>
>>
>
> Thanks.
>
