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: Tue, 11 Jun 2024 17:10:40 +0000
From: Charles Keepax <ckeepax@...nsource.cirrus.com>
To: Mark Brown <broonie@...nel.org>
CC: Richard Fitzgerald <rf@...nsource.cirrus.com>,
        <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 Tue, Jun 11, 2024 at 05:12:06PM +0100, Mark Brown wrote:
> On Tue, Jun 11, 2024 at 03:57:46PM +0100, Richard Fitzgerald wrote:
> > If the ASP1 DAI is hooked up by the machine driver the ASP TX mixer
> > sources should be initialized to disconnected.
> > 
> > The silicon default is for the mixer source registers to default to
> > a collection of monitoring sources. The problem with this is that it
> > causes the DAPM graph to initialize with the capture path connected
> > to a valid source widget, even though nothing setup a path. When the
> > ASP DAI is connected as a codec-to-codec link this will cause the other
> > codec to power-up even though nothing is using it.
> > 
> > Signed-off-by: Richard Fitzgerald <rf@...nsource.cirrus.com>
> > Fixes: dfd2ffb37399 ("ASoC: cs35l56: Prevent overwriting firmware ASP config")
> 
> 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
> default?  There were some other devices with things like bypass routes
> set up.  The capture path getting spuriously triggered feels like
> something that should just be sorted in general (TBH I thought that
> worked OK but it's been quite some time since I looked properly).

Mostly the problem here is it causes a bunch of errors in the
kernel log. The cs42l43 can only be clocked from the soundwire,
and the rate of that is only passed to the cs42l43 when audio plays.
When the ALSA control restore runs, you end up with a temporary route
(cs42l43 VMON -> cs35l56 ASP -> cs42l43 ASP -> cs42l43 Speaker). But
as there is no audio at that point there are no settings for the
PLL. I don't think it causes any lasting issues, but it does cause a
bunch of fat warnings in the log which people then complain about.
Plus also having things not routed by default is just nicer,
especially when the defaults are things that are an actual source
so likely to cause things to power up inadvertantly.

Thanks,
Charles