From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Splitting out controls Date: Fri, 16 Oct 2015 19:00:40 +0200 Message-ID: References: <1444657786.2528.78.camel@loki> <20151012205908.GA25971@us.netrek.org> <561CADA8.3040903@canonical.com> <1445009730.3536.18.camel@rf-debian.wolfsonmicro.main> <1445013114.3536.28.camel@rf-debian.wolfsonmicro.main> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id B0D3B260471 for ; Fri, 16 Oct 2015 19:00:41 +0200 (CEST) In-Reply-To: <1445013114.3536.28.camel@rf-debian.wolfsonmicro.main> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Richard Fitzgerald Cc: alsa-devel@alsa-project.org, James Cameron , David Henningsson List-Id: alsa-devel@alsa-project.org On Fri, 16 Oct 2015 18:31:54 +0200, Richard Fitzgerald wrote: > > On Fri, 2015-10-16 at 18:00 +0200, 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. > > > > > > Takashi > > OK, I didn't know that but I do now, so that wasn't a good example. But > how about something more complex. Let's say it was a set of coefficient > values for a filter. That's not a simple range check, it would need > specialized code to understand whether the coefficients were safe. > > Really my point was that if all hardware was completely isolated from > other hardware you can error-check controls. But when you start hooking > up bits of hardware to other bits of hardware, it becomes more complex > defining what is safe, and who is responsible for checking that it is > safe, and where the knowledge about how to check it's safe should live. > > That said, I'm not a fan of the "unless we can fix everything we > shouldn't fix anything" attitude. Fixing something is always better than > fixing nothing. So the fact that combining real hardware can introduce > new types of unsafe settings isn't an argument against error-checking > control values. Sure, systems will get more complex in future and more dynamic via f/w. It's impossible to cover all statically in each driver. As I mentioned in another mail, we should think of hardening in multiple levels. Takashi