linux-kernel - Re: [PATCH 08/18] ASoC: cs35l56: Fix default SDW TX mixer registers

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]

Message-ID: <11280dec-cf3d-1694-d837-2bf263ad148a@linux.intel.com>
Date: Tue, 30 Jan 2024 12:12:36 +0100
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To: Richard Fitzgerald <rf@...nsource.cirrus.com>, broonie@...nel.org,
 tiwai@...e.com
Cc: alsa-devel@...a-project.org, linux-sound@...r.kernel.org,
 linux-kernel@...r.kernel.org, patches@...nsource.cirrus.com
Subject: Re: [PATCH 08/18] ASoC: cs35l56: Fix default SDW TX mixer registers


>>> CS35L56 is designed for SDCA and a generic SDCA driver would
>>> know nothing about these chip-specific registers. So the
>>> firmware sets up the SDW TX mixer registers to whatever audio
>>> is relevant on a specific system.
>>>
>>> This means that the driver cannot assume the initial values
>>> of these registers. But Linux has ALSA controls to configure
>>> routing, so the registers can be patched to silicon default and
>>> the ALSA controls used to select what audio to feed back to the
>>> host capture path.
>>
>> humm, which has the precedence then?
>> a) the values set by firmware
>> b) the default values set by the driver?
>>
>> Also if the firmware touches those registers shouldn't they be marked as
>> 'volatile'?
>>
> 
> The firmware was designed to work with Windows, so it looks a bit
> strange if you are coming at it from ALSA. There's not really any
> defined 'precedence'. The firmware will setup the feedback monitor paths
> to something that satisfies SDCA and Windows expectations.
> 
> We don't care about that in Linux, the firmware on the Intel DSP
> probably isn't running the same algorithms for Linux, and we have ALSA
> controls to configure those paths. So we patch the mixers back to their
> silicon defaults and take over complete control of them.
> 
> The firmware only writes them during its power-up sequence so they
> will only change when we are rebooting the firmware or coming out of
> low-power standby, which is under the control of the driver. When that
> happens regmap will re-apply the patch and then sync up the registers
> again. The firmware won't touch them after boot, so we can avoid having
> to mark them volatile (which would mean implementing our own manual
> caching of the settings).

ok, thanks for the explanations.