Re: [PATCH v2] ASoC: cs35l56: Fix probe deadlock waiting for SoundWire enumeration

[Richard Fitzgerald]

On 13/08/2026 8:06 pm, Mark Brown wrote:
> On Thu, Aug 13, 2026 at 06:37:01PM +0100, Richard Fitzgerald wrote:
> > Defer all the parts of cs35l56_component_probe() that require register
> > access to a work item. This is to prevent a deadlock where
> > cs35l56_component_probe() is waiting for init_completion to be signaled
> > but is blocking the code that would signal it.
>
> >   static void cs35l56_wait_dsp_ready(struct cs35l56_private *cs35l56)
> >   {
> >   	/* Wait for patching to complete */
> > +	flush_work(&cs35l56->deferred_component_init_work);
> >   	flush_work(&cs35l56->dsp_work);
> >   }
> >   
>
> This can be called from asoc_sdw_cs_spk_rtd_init() when limiting the
> volume, that's still synchronous while setting up the card - the main

Mark beats Codex and Sashiko for finding a path that still deadlocks.

> Speaker Volume control uses cs35l56_dspwait_{get,put}_volsw() and when
> we set up the volume limit we at least read the current volume.  The
> deferred work will block on init_completion and error out if that times
> out but init_completion is still signalled in the callback that's
> blocked waiting for probe().

I think those waits in the control get/put are now obsolete and could
be removed. Originally it was in case the fw tuning patched the memory
to different values. But for other reasons the regmap patch now zeros
those memory locations, overwriting anything the tuning patched.

> AFAICT we always try to limit the volume for these speakers?
>
> I think the component registration needs to be moved out of probe into a
> work item...

That's the smallest code change, but can snd_soc_register_component()
return -EPROBE_DEFER?