[alsa-devel] Splitting out controls

[Pierre-Louis Bossart]

On 10/13/15 2:07 AM, David Henningsson wrote:
>
>
> On 2015-10-12 22:59, James Cameron wrote:
>> On Mon, Oct 12, 2015 at 02:49:46PM +0100, Liam Girdwood wrote:
>>> I've written up the minutes here below
>>
>> Thanks!
>>
>>> Splitting out controls: Takashi
>>> ===============================
>>>
>>>   - Restricted access.  Consensus to restrict access to some controls
>>> due
>>> to possibility of breaking HW at kernel level. i.e. prevent feeding
>>> digital Mic into HP amp to prevent speaker over heating.
>>
>> I'd like that.  rt5631.  Avoiding at the moment by removing the controls.
>
> IIRC, the debate was over "do not expose dangerous controls to userspace
> at all" vs "expose dangerous controls controls only to root".
>
> I'm strongly voting for "do not expose to userspace at all".
>
> I personally believe that if the physical hardware can be set to state
> where it's bricked, the hardware itself is buggy.
>
> If the hardware is buggy, this should be worked around in BIOS or
> whatever firmware is present on the machine. Otherwise there is a bug in
> BIOS.
>
> If BIOS is buggy and cannot protect the machine from being physically
> damaged, then we need to work around that in the kernel. Otherwise there
> is a bug in the kernel.
>
> And if the kernel is buggy, we should fix the kernel. Period. :-)

There are just too many variables linked to acoustic, mechanical and 
thermal design that just can't be handled with a simple rule at the 
kernel level or even BIOS/firmware. There were quite a few people in the 
room who voiced their opinion that handling 'dangerous' controls was an 
exercise for the integrator, not something that can be handled with a 
one-size-fits-all fix. 'userspace' is also a vague definition, most 
audio servers will use profiles that will avoid using bad 
configurations. It's not clear to me that we have to protect against a 
user setting random values with alsamixer.