All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keyon <yang.jie@linux.intel.com>
To: David Henningsson <david.henningsson@canonical.com>,
	James Cameron <quozl@laptop.org>,
	alsa-devel@alsa-project.org
Subject: Re: Splitting out controls
Date: Tue, 13 Oct 2015 16:27:26 +0800	[thread overview]
Message-ID: <561CC06E.8050707@linux.intel.com> (raw)
In-Reply-To: <561CADA8.3040903@canonical.com>


On 2015年10月13日 15:07, 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 that also we don't expose dangerous controls at all, or expose 
but do some restraining at codec driver side, e.g. changing dangerous 
setting to save one.
We *cannot* make sure 'root' may know the detail about it and leave the 
risk to him. :)

~Keyon

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

  reply	other threads:[~2015-10-13  8:21 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-12 13:49 [Minutes] ELCE Audio mini conf Liam Girdwood
2015-10-12 15:30 ` Jaroslav Kysela
2015-10-12 20:59 ` Splitting out controls James Cameron
2015-10-13  7:07   ` David Henningsson
2015-10-13  8:27     ` Keyon [this message]
2015-10-13 14:55     ` Pierre-Louis Bossart
2015-10-13 15:56       ` David Henningsson
2015-10-13 16:08         ` Pierre-Louis Bossart
2015-10-16  6:41           ` David Henningsson
2015-10-16 14:49             ` Pierre-Louis Bossart
2015-10-16 15:24               ` Richard Fitzgerald
2015-10-30  2:48                 ` Mark Brown
2015-10-16 15:28               ` Takashi Iwai
2015-10-14 18:20         ` Liam Girdwood
2015-10-16 15:35     ` Richard Fitzgerald
2015-10-16 16:00       ` Takashi Iwai
2015-10-16 16:31         ` Richard Fitzgerald
2015-10-16 17:00           ` Takashi Iwai
2015-10-17 15:54         ` Pierre-Louis Bossart
2015-10-17 16:02           ` Takashi Iwai
2015-10-18  6:41             ` Ricard Wanderlof
2015-10-30  2:57               ` Mark Brown
2015-10-17 16:25           ` Alexander E. Patrakov
2015-10-30  2:50       ` Mark Brown
2015-10-30  2:36     ` Mark Brown
2015-10-30  8:36       ` David Henningsson
2015-10-30  8:53         ` James Cameron
2015-10-30  9:04           ` David Henningsson
2015-11-01  2:45             ` Mark Brown
2015-10-13 14:09 ` 'BATCH flag for USB' and 'ALSA Core Challenges' Takashi Sakamoto
2015-10-13 14:44   ` Alexander E. Patrakov
2015-10-18  3:22     ` Takashi Sakamoto
2015-10-13 16:01   ` Pierre-Louis Bossart
2015-10-14 12:27   ` Liam Girdwood
2015-10-22 17:10 ` [Minutes] ELCE Audio mini conf Mark Brown
2015-10-22 17:14 ` DP hotplug on USB C Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=561CC06E.8050707@linux.intel.com \
    --to=yang.jie@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=david.henningsson@canonical.com \
    --cc=quozl@laptop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.