On Tue, Nov 03, 2020 at 04:58:59AM -0800, Perry Yuan wrote:
> From: perry_yuan <perry_yuan@xxxxxxxx>
>
> Some new Dell system is going to support audio internal micphone
> privacy setting from hardware level with micmute led state changing
>
> This patch allow to change micmute led state through this micphone
> led control interface like hda_generic provided.
If this is useful it should be done at the subsystem level rather than
open coded in a specific CODEC driver, however I don't undersand why it
is.
> +static int rt715_micmute_led_mode_put(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_value *ucontrol)
> +{
> + struct snd_soc_component *component = snd_kcontrol_chip(kcontrol);
> + struct rt715_priv *rt715 = snd_soc_component_get_drvdata(component);
> + int led_mode = ucontrol->value.integer.value[0];
> +
> + rt715->micmute_led = led_mode;
> +#if IS_ENABLED(CONFIG_LEDS_TRIGGER_AUDIO)
> + ledtrig_audio_set(LED_AUDIO_MICMUTE,
> + rt715->micmute_led ? LED_ON : LED_OFF);
> +#endif
> + return 0;
> +}
This is just adding a userspace API to set a LED via the standard LED
APIs. Since the LED subsystem already has a perfectly good userspace
API why not use that? There is no visible value in this being in the
sound subsystem.
Please also follow the kernel coding style, your code doesn't visually
resemble the adjacent code.
Attachment:
signature.asc
Description: PGP signature
