No soundcards recognised by ALSA after upgrading from kernel 6.17.1 to 6.17.8 (Lenovo Yoga Slim 7 14ILL10) cs42l43

[emfol]

After upgrading to Linux kernel 6.17.8 (from 6.17.1) the sound card is no longer recognized.

I ran the alsa-info.sh script after booting kernel 6.17.1 and 6.17.8 and the results follow:

• 6.17.1: https://alsa-project.org/db/?f=5887d318c6cd7866365a0f134eeaf5721f33b82d
• 6.17.8: https://alsa-project.org/db/?f=a5ca95f07b9a1844c102f63e6c0e36cd2e5755ef

DMESG 6.17.8:

Nov 19 22:33:46 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: SoundWire enabled on CannonLake+ platform, using SOF driver
Nov 19 22:33:46 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: enabling device (0000 -> 0002)
Nov 19 22:33:46 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040100
Nov 19 22:33:46 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: bound 0000:00:02.0 (ops intel_audio_component_bind_ops [xe])
Nov 19 22:33:46 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: use msi interrupt mode
Nov 19 22:33:46 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: hda codecs found, mask 4
Nov 19 22:33:46 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: NHLT device BT(0) detected, ssp_mask 0x4
Nov 19 22:33:46 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: BT link detected in NHLT tables: 0x4
Nov 19 22:33:46 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: DMICs detected in NHLT tables: 4
Nov 19 22:33:46 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: Firmware paths/files for ipc type 1:
Nov 19 22:33:46 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3:  Firmware file:     intel/sof-ipc4/lnl/sof-lnl.ri
Nov 19 22:33:46 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3:  Firmware lib path: intel/sof-ipc4-lib/lnl
Nov 19 22:33:46 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3:  Topology file:     intel/sof-ipc4-tplg/sof-lnl-cs42l43-l0-4ch.tplg
Nov 19 22:33:46 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: Loaded firmware library: ADSPFW, version: 2.13.0.1
Nov 19 22:33:46 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: Booted firmware version: 2.13.0.1

DMESG 6.17.1:

Nov 19 22:22:14 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: SoundWire enabled on CannonLake+ platform, using SOF driver
Nov 19 22:22:14 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: enabling device (0000 -> 0002)
Nov 19 22:22:14 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040100
Nov 19 22:22:14 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: bound 0000:00:02.0 (ops intel_audio_component_bind_ops [xe])
Nov 19 22:22:14 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: use msi interrupt mode
Nov 19 22:22:14 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: hda codecs found, mask 4
Nov 19 22:22:14 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: NHLT device BT(0) detected, ssp_mask 0x4
Nov 19 22:22:14 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: BT link detected in NHLT tables: 0x4
Nov 19 22:22:14 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: DMICs detected in NHLT tables: 4
Nov 19 22:22:14 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: Firmware paths/files for ipc type 1:
Nov 19 22:22:14 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3:  Firmware file:     intel/sof-ipc4/lnl/sof-lnl.ri
Nov 19 22:22:14 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3:  Firmware lib path: intel/sof-ipc4-lib/lnl
Nov 19 22:22:14 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3:  Topology file:     intel/sof-ipc4-tplg/sof-lnl-cs42l43-l0-4ch.tplg
Nov 19 22:22:14 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: Loaded firmware library: ADSPFW, version: 2.13.0.1
Nov 19 22:22:15 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: Booted firmware version: 2.13.0.1
Nov 19 22:22:15 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: Topology: ABI 3:29:1 Kernel ABI 3:23:1
Nov 19 22:22:15 ys7i14-em kernel: sof_sdw sof_sdw: ASoC: Parent card not yet available, widget card binding deferred
Nov 19 22:22:15 ys7i14-em kernel: sof-audio-pci-intel-lnl 0000:00:1f.3: Loaded firmware library: ADSPFW, version: 2.13.0.1
Nov 19 22:22:21 ys7i14-em kernel: sof_sdw sof_sdw: Setting CS42L43 Speaker volume limit to 128
Nov 19 22:22:21 ys7i14-em kernel: sof_sdw sof_sdw: hda_dsp_hdmi_build_controls: no PCM in topology for HDMI converter 3
Nov 19 22:22:21 ys7i14-em kernel: input: sof-soundwire Jack as /devices/pci0000:00/0000:00:1f.3/sof_sdw/sound/card0/input14
Nov 19 22:22:21 ys7i14-em kernel: input: sof-soundwire HDMI/DP,pcm=5 as /devices/pci0000:00/0000:00:1f.3/sof_sdw/sound/card0/input15
Nov 19 22:22:21 ys7i14-em kernel: input: sof-soundwire HDMI/DP,pcm=6 as /devices/pci0000:00/0000:00:1f.3/sof_sdw/sound/card0/input16
Nov 19 22:22:21 ys7i14-em kernel: input: sof-soundwire HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1f.3/sof_sdw/sound/card0/input17
Nov 19 22:33:07 ys7i14-em systemd[1]: sys-devices-pci0000:00-0000:00:1f.3-sof_sdw-sound-card0-controlC0.device: Failed to enqueue SYSTEMD_WANTS job, ignoring: Transaction for sound.target/start is destructive (reboot.target has 'start' job queued, but 'stop' is included in transaction).

[charleskeepax]

The log snippets from the failing case don't seem to give a lot of clues, would it be possible to get a full dmesg from the failing system please?

[emfol]

The log snippets from the failing case don't seem to give a lot of clues, would it be possible to get a full dmesg from the failing system please?

Sure.

dmesg_20251120.txt

Thanks, @charleskeepax .

[charleskeepax]

I think this is culprit:

[ 3108.995120] cs42l43-codec cs42l43-codec: Failed to resume for tip work: -13

Looking at the stable trees I think the problem might be commit 62aec8a ("mfd: cs42l43: Move IRQ enable/disable to encompass force suspend") I wonder if backporting that without the other patches in the chain caused some issues, although its not super clear to me why it would.

Are you comfortable building a kernel? If so it would be really helpful to try reverting that change and seeing if that fixes your issue. Alternatively if you had access to one of the v6.18-rcX kernels that should include the accompanying other patches so testing that would be interesting too.

[emfol]

Only today I could take the time to revert that patch and rebuild the kernel.

That message -- Failed to resume for tip work -- seems to be gone now but still no soundcard detected.

dmesg_20251122.txt

[emfol]

Another (unsuccessful) build reverting this commit: 45f5c9e.

dmesg_20251123.txt

[charleskeepax]

Hmm... apologies for this one, and the wild goose chase with that previous guess. Whilst investigating some other stuff I think I inadvertently stumbled on what is causing your problem end of last week. The actual problem patch is:

commit 25decf0 ("gpio: swnode: don't use the swnode's name as the key for GPIO lookup")

If you revert that one I am pretty confident things will start working again. The Slim 7 uses a topology we call bridge where the amps are connected to the codec and this patch interferes with the registration of those which is likely causing bits of the soundcard to be missing. There is a fix which is a part of these series:

https://lore.kernel.org/linux-sound/4e26c38c17fdcecc0e3fc119222568bc543f870b.camel@pengutronix.de/

You would need the first 5 patches hopefully they will make there way back to 6.17 stable soon, but for now reverting that offending patch is probably easier than backporting those 5 patches. They might require something more than simple cherry picking to backport.

[emfol]

Thanks, @charleskeepax.

I just confirmed that reverting the change from that single commit on 6.17.8 tree gets audio working again on Yoga Slim 7i 14.

Should I close this issue?

[charleskeepax]

Lets leave this open for now until we get a fix into stable.

[charleskeepax]

OK a revert should have gone into stable now:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=queue/6.17

So I think this should be fixed once v6.17.10 comes out. So we can probably close the issue now.

[emfol]

That's good news. Thanks, @charleskeepax.