[RFC 2/2] ASoC: rt5670: Add LED trigger support

[Hans de Goede]

Hi,

On 2/25/21 3:59 PM, Mark Brown wrote:
> On Wed, Feb 24, 2021 at 09:09:36PM +0100, Hans de Goede wrote:
> 
>> 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
> 
> This seems like an optimistic set of assumptions - it may reflect
> current laptops but it sounds like the sort of thing people might
> deploy on future devices, never mind all the non-laptops that could end
> up wanting to use this mechanism.
> 
>> 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.
> 
> Again, this only works in cases where there's only one option for the
> control that could be used.

Which is the case in all the current models which I'm trying to get
the mute LED supported on.  In its current form this is all purely
handled inside the kernel, so we can easily change / extend the mechanism
later without any problems.

OTOH adding an interface where userspace can runtime set which control
to use for this, would require adding some userspace API for this.

To me it seems like a really bad idea to add userspace API for this now,
when we don't actually have hardware which needs this. Introducing
userspace API for this now introduces a significant risk that we get the
API wrong, since we don't actuall have a use-case where we actually need
the suggested flexibility. And then if such a use-case does eventually
pop-up we might very well have gotten the userspace API for this wrong.

I'm not saying that we will never need such flexibility, but we do not
need it *now*, so as I said before lets cross that bridge when we reach it. 

Regards,

Hans