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.