On Tue, Feb 23, 2021 at 05:14:32PM +0100, Jaroslav Kysela wrote:
Dne 23. 02. 21 v 15:21 Takashi Iwai napsal(a):
That's one of my concerns in the recent actions for putting the hard-coded mute LED controls. So far, the only usage of led-audio trigger is HD-audio, and it's enabled only for selected devices and setups. OTOH, if we apply the audio-led trigger generically in ASoC codec driver, it's always done and might misfit; e.g. what happens if two codecs are present on the system?.
That's the abstraction issue. We can use PCI, ACPI, DMI or DT checks at the _right_ place (machine top-level code) to mark those controls with the LED flags in the kernel space. I've never said that the right place is the generic ASoC codec driver.
We already need ACPI and DMI quirks in the CODEC drivers anyway due to the limitations of ACPI so it wouldn't be particularly surprising to have stuff there. OTOH this would fix things per machine while with fancier hardware things might easily be flexible enough that there's multiple choices that could be made depending on use case.
I'd be a lot more comfortable with ASoC having some runtime control for overriding which controls get mapped, even if we try to pick defaults with quirks.