Re: [PATCH] ASoC: core: Move all users to deferrable card binding

["Péter Ujfalusi" <peter.ujfalusi@linux.intel.com>]

On 25/05/2026 18:06, Mark Brown wrote:
> On Mon, May 25, 2026 at 03:48:36PM +0300, Péter Ujfalusi wrote:
>> On 22/05/2026 17:58, Mark Brown wrote:
>>> On Fri, May 22, 2026 at 04:32:03PM +0200, Cezary Rojewski wrote:
> 
>>>> The question on the table:  Do we revert the change temporarily, fix the SOF
>>>> first and then re-apply the patch again?
> 
>>> Given that there's two drivers we managed to turn up bugs in already I'm
>>> inclined to leave the patch there so it's more likely that any other
>>> issues get found.  It's a bit annoying for SOF CI but I guess a revert
>>> can be merged locally there?
> 
>> It is not really the SOF CI but the users. it looks like all codecs
>> using SDCA infra is affected and will fail to probe audio on boot.
> 
> Hang on, are you saying you don't test -next or my ASoC branches at all?

We sort of test -next audio stuff in daily bases, but this would have
not been caught if I did not happen to be debugging something on a PTL
system with Cirrus codecs, using SDCA infra.

We do approximately weekly merges of -next audio branches to our sof-dev
working tree, our pending patch deficit usually pretty shallow to allow
testing before sending them upstream (we have sof-dev-rebase branch as
well to see them cleanly).

> It sounded like this was the result of a merge with some out of tree
> stuff you have with Cezary's change but it sounds like you're saying
> there are issues independently of the merge.

No, it is not out of tree stuff, it is upstream stuff already in use for
SDCA proper codecs, but I think what really triggers this is
c5ae3d8bc968 ("ASoC: soc_sdw_utils: partial match the codec name")
which is in 7.1-rc1, so not next stuff either.

I think the issue boils down to the fact that we don't know the exact
name of the SDCA codec and DAI for the function before they have been
created, thus the sof_sdw machine relies on deferring to 'see' the names
they got.

I think Bard and Charles are the best persons to comment, but atm Cirrus
codecs are the ones pioneering the use of generic sdca codec class
driver with Realtek and TI preparing to enable it.

I also think that detaching from driver defer and use internal card
defer is a much better approach, but when majority of new PTL designs
will be broken with no patch in sight to prepare the SDCA class stack is
a regression.

Charles, Bard, Richard, Simon, any thoughts on this?

-- 
Péter