Hi, On 2/24/21 8:36 PM, Mark Brown wrote: > On Wed, Feb 24, 2021 at 08:14:12PM +0100, Hans de Goede wrote: >> On 2/24/21 1:59 PM, Mark Brown wrote: > >>> The problem I was thinking of is the situation where there are multiple >>> options for the mute control in the hardware and it's a configuration >>> decision which one to use. > >> ATM we have no device where this situation happens, so I would prefer >> to cross that bridge when we come to it. > > You just added wm5012 machine drivers, that device is going to present > issues with this approach. I've no intention to add led-trigger support to the bytcr-wm5102 driver, since to the best of my knowledge there are no mute LEDs on any designs using the bytcr + wm5102 combination. I'm aware of there actually being a mute LED on only 3 2-in-1 models with detachable keyboards (with the mute LEDs sitting inside the media-keys to toggle the mute, like how it is done on thinkpads): 1. The Thinkpad10 bytcr+rt5670 tablet with its USB ultrabook keyboard dock 2. The HP x2 10" clamshell designs with detachable keyboards in 2 variants, bytcr + rt5640 and cht + rt5640. Thats it, and in both cases the codecs have main ADC / DAC volume controls which are the only ones suited for using as the control to drive the led-trigger. Which is why this RFC just hardcoded the trigger to that control. As I said I'll happily respin this RFC series (and the not yet posted similar rt5640 series) to tie the led-trigger to specific controls based on DMI quirks. Given that the use of mute LEDs itself is actually rare and especially the use of mute LEDs in combination with ASoC coming up with some generic configuration mechanism to allow userspace to tie the led-trigger to any random 'Switch' type control is way overkill / overengineering and I've no desire to spend a huge amount of time on implementing this. Not to mention that this would just be punting the actual problem of figuring out which control to use to userspace, while the kernel is actually in a better place to make this decision since the kernel already uses DMI based quirks to deal with model specific configuration. Regards, Hans
