linux-kernel - Re: [PATCH] ASoC: cs35l56: Disconnect ASP1 TX sources when ASP1 DAI is hooked up

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] [thread-next>] [day] [month] [year] [list]

Date: Wed, 12 Jun 2024 11:42:15 +0100
From: Richard Fitzgerald <rf@...nsource.cirrus.com>
To: Mark Brown <broonie@...nel.org>
CC: <linux-kernel@...r.kernel.org>, <patches@...nsource.cirrus.com>,
        <alsa-devel@...a-project.org>, <linux-sound@...r.kernel.org>
Subject: Re: [PATCH] ASoC: cs35l56: Disconnect ASP1 TX sources when ASP1 DAI
 is hooked up

On 12/06/2024 11:19, Mark Brown wrote:
> On Wed, Jun 12, 2024 at 10:19:06AM +0100, Richard Fitzgerald wrote:
>> On 11/06/2024 17:12, Mark Brown wrote:
> 
>>> This doesn't seem particularly different to any other unhelpful chip
>>> default, I'm not sure why it'd be so urgent that we'd hard code a
> 
>> I'm not sure I understand the objection here. Are you objecting to the
>> patch itself, or that I marked it as a Fixes?
> 
> Both I guess, but mainly the patch itself - we generally have an
> extremely high bar for setting defaults different to the chip defaults
> to avoid issues with differing use cases.

But that's somewhat part of the problem. There's no such thing as a chip
default for the cs35l56 because for Windows reasons the firmware patches
up all the registers on boot to setup a hardcoded use-case configuration
so that the Windows SDCA drivers can be generic and don't need knowledge
of chip-specific registers. The firmware is customized per end-product,
so the initial register state can vary.

The driver currently attempts to sync-up the mixer registers with what
the firmware set them to, which means that the initial starting state
of the ALSA controls can vary between products using the cs35l56, and
in theory even between revisions of the firmware if there was a need
to change the routing setup for Windows. We don't really need to do
that on Linux - it has a use-case manager and ALSA controls for this
stuff, and the code to do all the syncing-up adds a lot of driver
complexity. We want to remove that complexity, and instead patch the
registers back to silicon defaults - obliterate the Windows use-case
setup and use standard Linux mechanisms to setup what is required.

However, the mixer settings were already causing a bunch of log
warnings. So I decided to split this fix off so it's not dependent on a
big code revert.

I can send a V2 of this patch with this long explanation of the
background. I didn't put it all in V1 because it never occurred to me
that defaulting the mixer sources would be controversial.