linux-kernel - Re: [PATCH] ASoC: tas2562: Add support for digital volume control

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <7e08798f-ec91-1eb2-c082-cfbccc6d6202@ti.com>
Date:   Thu, 20 Feb 2020 13:52:55 -0600
From:   Dan Murphy <dmurphy@...com>
To:     Mark Brown <broonie@...nel.org>
CC:     <lgirdwood@...il.com>, <perex@...ex.cz>, <tiwai@...e.com>,
        <alsa-devel@...a-project.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ASoC: tas2562: Add support for digital volume control

Mark

On 2/20/20 1:40 PM, Mark Brown wrote:
> On Thu, Feb 20, 2020 at 01:22:34PM -0600, Dan Murphy wrote:
>> On 2/20/20 1:18 PM, Mark Brown wrote:
>>> decisions causing changes in the driver.  The system may have an
>>> external amplifier they prefer to use for hardware volume control, may
>>> prefer to do entirely soft volume control in their sound server or
>>> something like that.
>> But this is an amplifier.  Not sure why the system designer would design
>> cascading amplifiers.
>> And if that was the case wouldn't you want the output to be low so you don't
>> overdrive the ext amplifier front end?
> The point is that we don't know what people are doing and should try to
> keep the kernel out of policy decisions unless there's something that's
> clearly just unconditionaly right for all systems.  It's a lot easier to
> just have a clear rule that we defer to the wisdom of the silicon vendor
> than try to get into defaults, and it's a lot easier to just do this as
> consistently as we can rather than debating individual configuration
> changes.
>
I completely agree on keeping policy decisions out of the kernel.

>> I was considering safety in that the device is on at full blast (not sure
>> why the HW is defaulted that way but it is).
> I bet there's been issues with people turning things on and not
> realising they need register writes to hear anything, and the volume
> control here is a bit complex as well.
Ack
>
>> But if volume is adjusted prior to playback then this is not an issue.  But
>> if volume is not adjusted then it plays full blast.
> Wouldn't be the first time.  See all the dual purpose headphone/line
> outputs that people build, sensible defaults for headphones and line
> outputs are rather different.

OK.  I will remove them. Will do v3 tomorrow as v2 rearranged the values 
properly.  V3 will remove them.

Dan