Re: [REGRESSION 7.2-rc3] ASoC: cs35l56: compo nent probe waits for an init_completion that cannot be signalle d until the wait ends — whole sof_sdw card fails

On 15/07/2026 4:08 pm, Salman S. Tahir wrote:
> Hi,
> 
> On a Lenovo Yoga 9 2-in-1 14ILL10 (83LC, Core Ultra 7 258V / Lunar Lake; 
> CS42L43
> plus two SPI-attached CS35L56 amps behind it) the machine has no sound 
> card at all
> on 7.2-rc3. /proc/asound/cards is empty and PipeWire falls back to a 
> null sink.
> 
> The right-hand amp's ASoC component probe times out waiting for 
> init_completion,
> returns -ENODEV, and ASoC then tears down the entire card -- so 
> speakers, internal
> mics, headset and all three HDMI outputs die because of one failed 
> component:
> 
> [ 10.301...] cs35l56 spi-cs35l56-right: _cs35l56_component_probe: 
> init_completion timed out
> [ 10.301...] cs35l56 spi-cs35l56-right: ASoC error (-19): at 
> snd_soc_component_probe() on spi-cs35l56-right
> [ 10.302...] sof_sdw sof_sdw: ASoC: failed to instantiate card -19

<SNIP>

> The hardware is fine -- the card is just built ~100 ms too early

This (and the later debug and hypothesis) doesn't actually make any
sense. The code that signals init_completion is done synchronously
during the driver probe() of the cs35l56 driver, before it returns
from probe().

However there is a bug if component_probe() can be called multiple
times.

Please try this change:

diff --git a/sound/soc/codecs/cs35l56.c b/sound/soc/codecs/cs35l56.c
index f365f76ce56c1..f46fd8e7bc039 100644
--- a/sound/soc/codecs/cs35l56.c
+++ b/sound/soc/codecs/cs35l56.c
@@ -2109,7 +2109,7 @@ int cs35l56_init(struct cs35l56_private *cs35l56)
                 return dev_err_probe(cs35l56->base.dev, ret, "Failed to 
write ASP1_CONTROL3\n");

         cs35l56->base.init_done = true;
-       complete(&cs35l56->init_completion);
+       complete_all(&cs35l56->init_completion);

         return 0;
  }


<SNIP>
> Regardless of what changed the ordering, blocking in a component probe 
> on a completion
> that a different probe must signal looks fragile by construction. Returning
> -EPROBE_DEFER instead -- letting the driver core retry the card once the 
> amp is bound

Returning -EPROBE_DEFER from component_probe() would make no difference
to that, because the code that signals the completion has already run
during probe(). Returning -EPROBE_DEFER from component_probe() won't
make probe() run again.

Also it's wrong to use -EPROBE_DEFER as a general "try again later". It
doesn't work like that. It specifically means that a dependency is not
ready yet and the driver core will try again only when something other
driver has successfully probed.

Be careful of what AI tells you.