[alsa-devel] Splitting out controls

[Takashi Iwai]

On Sat, 17 Oct 2015 17:54:09 +0200,
Pierre-Louis Bossart wrote:
> 
> On 10/16/15 11:00 AM, Takashi Iwai wrote:
> > 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.
> 
> To say that a configuration is 'safe' requires a breadth of information 
> from thermal, acoustic and mechanical design that is just not available 
> to kernel contributors who work in parallel on different building blocks 
> and different configurations. Adding a safeguard in the machine driver 
> is not practical: it's not uncommon for manufacturers to swap out 
> speakers to save a couple of cents on a specific production batch and a 
> value set in stone in a driver would not work for all those different 
> batches.
> So yes everyone should try and make sure that there are no 'dangerous' 
> controls at their individual level but there is no way to protect 
> hardware integrity in all cases if users punch-in values in alsamixer.

The question is *which* user.  If it's a system user for a daemon or a
management tool, it's fine.  But if it's a normal user, it's bad.  My
original proposal (the separation of access levels) came from this
POV.

I won't say that we can always save the world.  But there is certainly
a room for improvement for a little bit more safety than now.  At
least, if hardware manufacturer or system integrator already knows the
dangerous part, we should provide some easy way to paper over it.


Takashi