linux-kernel - Re: [PATCH 1/3] ASoC: SDCA: Create DAPM widgets and routes from DisCo

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: <Z/97SwfaLp2VIzf4@opensource.cirrus.com>
Date: Wed, 16 Apr 2025 10:41:31 +0100
From: Charles Keepax <ckeepax@...nsource.cirrus.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@...ux.dev>
Cc: broonie@...nel.org, lgirdwood@...il.com, yung-chuan.liao@...ux.intel.com,
        peter.ujfalusi@...ux.intel.com, linux-sound@...r.kernel.org,
        linux-kernel@...r.kernel.org, patches@...nsource.cirrus.com
Subject: Re: [PATCH 1/3] ASoC: SDCA: Create DAPM widgets and routes from DisCo

On Mon, Apr 14, 2025 at 02:43:50PM -0500, Pierre-Louis Bossart wrote:
> >> How would the state of those DAPM SU widgets be updated
> >> though? I think we need to 'translate' the GE settings to tell
> >> DAPM which paths can become active, but the SUs state is set
> >> by hardware so I could see a possible racy disconnect if we
> >> make a path activable but hardware hasn't done so yet.
> > 
> > All the SU DAPM widgets are linked to the single GE control,
> > the same ALSA control is shared across all the widgets. So
> > all the paths are updated in a single DAPM sync, and on the
> > hardware side with a single write to the GE control.
> 
> The race I am concerned about is between SU values
> represented in DAPM and actual values propagated inside the
> SDCA device. There could be a delay between writing a GE
> register and the SU register values changing.

Fair enough, but I don't see why this matters. Those SU registers
are device level, it is the devices business to manage them. Why
does it matter if there is a delay updating them? All the widgets
on the host side are controlled by the GE control.

> > To put that as a more concrete example this code will create
> > input widgets for IT 31, 32, 33 (the UAJ mics), however it
> > would be unusual to hook a pin switch to those. Something
> > should be creating an actual microphone widget, attaching
> > that to the input widgets and attaching a pin switch to that.
> > Typically those actions are handled in the machine driver,
> > there is possibly an argument for handling them in the codec
> > driver for SDCA but I felt it would make more sense to progress
> > things a little further until resolving that one.
> 
> The SDCA spec is supposed to describe what's physically
> connected, so when we parse the DisCo descriptors we should
> only see the level that is typically present in machine
> drivers.

That's not entirely true, none of the interconnections between
codecs are contained. Microsoft invented that composition stuff
to hold that sort of stuff. Although perhaps there is a strong
case that the IT/OTs here are defined as having a mic/speaker
connected so it is the right place to define them?

> The codec descriptors are not generic at all, they
> should only describe a specific way of how a SDCA codec is
> used. The traditional split between codec and machine drivers
> does not really apply for SDCA, the SDCA descriptors represent
> the *machine* already.

I guess that makes your opinion very much that we do add the
mic/speaker widgets at this level. I mean it wouldn't take long
to add them. I am still not totally as sure, but we can probably
live with a little more effort to back it out if we need it. I
will do a v4 and see what adding those in looks like.

Thanks,
Charles