Hi,
On 2/23/21 10:12 AM, Pavel Machek wrote:
> Hi!
>
>> Some 2-in-1s with a detachable (USB) keyboard(dock) have mute-LEDs in
>> the speaker- and/or mic-mute keys on the keyboard.
>>
>> Examples of this are the Lenovo Thinkpad10 tablet (with its USB kbd-dock)
>> and the HP x2 10 series.
>>
>> The detachable nature of these keyboards means that the keyboard and
>> thus the mute LEDs may show up after the user (or userspace restoring
>> old mixer settings) has muted the speaker and/or mic.
>>
>> Current LED-class devices with a default_trigger of "audio-mute" or
>> "audio-micmute" initialize the brightness member of led_classdev with
>> ledtrig_audio_get() before registering the LED.
>>
>> This makes the software state after attaching the keyboard match the
>> actual audio mute state, e.g. cat /sys/class/leds/foo/brightness will
>> show the right value.
>
> Makes sense.
>
>> +++ b/drivers/leds/trigger/ledtrig-audio.c
>> @@ -6,10 +6,33 @@
>> #include <linux/kernel.h>
>> #include <linux/leds.h>
>> #include <linux/module.h>
>> +#include "../leds.h"
>>
>> -static struct led_trigger *ledtrig_audio[NUM_AUDIO_LEDS];
>> static enum led_brightness audio_state[NUM_AUDIO_LEDS];
>>
>> +static int ledtrig_audio_mute_activate(struct led_classdev *led_cdev)
>> +{
>> + led_set_brightness_nosleep(led_cdev, audio_state[LED_AUDIO_MUTE]);
>> + return 0;
>> +}
>
> Is mute_activate called from atomic context?
All the other ledtrig-foo.c activate callbacks use led_set_brightness_nosleep(),
so yes I would assume so (I did not check, I assumed the others have good
reasons to do this).
Regards,
Hans
