[alsa-devel] Splitting out controls

[James Cameron]

On Fri, Oct 30, 2015 at 09:36:39AM +0100, David Henningsson wrote:
> 
> 
> On 2015-10-30 03:36, Mark Brown wrote:
> >On Tue, Oct 13, 2015 at 09:07:20AM +0200, David Henningsson wrote:
> >>On 2015-10-12 22:59, James Cameron wrote:
> >
> >James, please don't drop CCs (this is the convention for kernel lists).
> >
> >>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.
> >
> >This is just not possible for most systems, there is no BIOS only a
> >bootoloader which hands off control to the kernel and stops running at
> >that point.
> 
> The BIOS can poke the hardware, set registers in such ways that
> volumes are limited. Registers that the kernel never touches.

I'm not sure how that would work.  The BIOS developers and the kernel
developers would have to agree on what registers are to be touched by
the BIOS only.  In my case, with the rt5631, the registers could not
be easily isolated in that fashion.  And if the kernel hit the reset
bit in one of the registers, whatever the BIOS had set would be lost.

Oh, and power management.  The codec can be powered down by suspend,
with the BIOS uninvolved in resume.

> From
> my knowledge, this is more common than not on modern laptops with
> HDA codecs. A bootloader could potentially do the same - but in many
> embedded setups I suspect it makes just as much sense to do that
> during driver initialization instead.
> 
> Anyhow, we both agree on the fact that sometimes there is no
> hardware and no BIOS that protect us against hardware failure.
> 
> We currently have some kind of mechanism that protects the end user
> from unintentionally destroying the hardware. What we're arguing
> about is whether that mechanism should be in userspace (e g by
> having the GUI talk to UCM instead of amixer directly), or in the
> kernel.
> 
> I'm advocating having it as close to the hardware as possible - i e,
> in the kernel, because that protects additional classes of users
> from unintentionally destroying the hardware. As well as making it
> harder for malicious apps that intentionally want to do it.
> 
> There is no calculation that userspace can do, that the kernel can't
> do almost as easily, so I don't buy the argument that doing things
> in the kernel would be "unrealistically difficult".
> However, it seems that we have done (IMO) such a gross mis-design
> that changing this isn't possible overnight. But can we then try to
> move in the right direction, instead of moving in the wrong one?
> 
> -- 
> David Henningsson, Canonical Ltd.
> https://launchpad.net/~diwic

-- 
James Cameron
http://quozl.linux.org.au/