[alsa-devel] Splitting out controls

[Takashi Iwai]

On Fri, 16 Oct 2015 17:35:30 +0200,
Richard Fitzgerald wrote:
> 
> On Tue, 2015-10-13 at 09:07 +0200, 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. :-)
> > 
> I agree with you in principle that if it can break the hardware then
> either it shouldn't be exposed to user-side at all, or it should be
> checked by the kernel/driver to prevent bad settings.
> 
> However, what about this sort of scenario: some codec has a speaker
> volume range of 0..100, all of which are valid and safe. Manufacturer X
> makes a device with an inadequate speaker that can be damaged with
> volume settings above 80. How is that protected? There's nothing wrong
> with the codec driver. There's no software at all for a speaker - it's
> just a speaker. Where do we put a hard limit of 80 on a codec control
> for one specific device? If it was my codec driver I don't want to have
> to put a workaround for one specific device because manufacturer X chose
> the wrong type of speaker. Or do we not care about the "stupid
> manufacturer" cases and we're only interested in protecting the device
> the control directly applies to - in this example it's a codec control
> so it mustn't damage the codec but we don't care if poor hardware design
> means it could damage other hardware connected to the codec.

There is snd_soc_limit_volume() function to override the volume range
from a machine driver for such a purpose.  This was what was suggested
in the meeting.


Takashi