[BUG] Audio regression 6.17.7 to 6.17.8: CS42L43 SPI controller registration fails on Lunar Lake

[kvn80]

Summary

Audio regression between kernel 6.17.7 and 6.17.8 on Intel Lunar Lake with Cirrus Logic CS42L43 codec via SoundWire. The SPI controller embedded in CS42L43 fails to register, blocking sound card initialization.

Hardware

• CPU: Intel Core Ultra 5 228V (Lunar Lake)
• Audio codec: Cirrus Logic CS42L43 (SoundWire ID: sdw:0:0:01fa:4243:01)
• Secondary codec: Realtek RT711 SDCA (SoundWire ID: sdw:0:0:025d:0711:01)
• Platform: Lenovo Yoga (Laptop)
• Topology: intel/sof-ipc4-tplg/sof-lnl-cs42l43-l0-4ch.tplg

Software

• Distribution: EndeavourOS (Arch-based)
• Working kernel: 6.17.7-arch1-1
• Broken kernel: 6.17.8-arch1-1, 6.17.8-zen1-1-zen, 6.12.59-1-lts
• SOF firmware: 2025.05.1-1 (version 2.13.0.1)
• linux-firmware: 20251111-1

Regression range

• Last working: 6.17.7
• First broken: 6.17.8

Steps to reproduce

1. Boot kernel 6.17.8 on Intel Lunar Lake system with CS42L43 codec
2. Run aplay -l
3. Observe: no soundcards found

Expected behavior (kernel 6.17.7)

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sofsoundwire [sof-soundwire], device 0: Jack Out (*) []
card 0: sofsoundwire [sof-soundwire], device 2: Speaker (*) []
[...]

Actual behavior (kernel 6.17.8)

$ aplay -l
aplay: device_list:279: no soundcards found...

dmesg on broken kernel (6.17.8)

[   11.635205] cs42l43 sdw:0:0:01fa:4243:01: supply vdd-p not found, using dummy regulator
[   11.635228] cs42l43 sdw:0:0:01fa:4243:01: supply vdd-d not found, using dummy regulator
[   11.635234] cs42l43 sdw:0:0:01fa:4243:01: supply vdd-a not found, using dummy regulator
[   11.635241] cs42l43 sdw:0:0:01fa:4243:01: supply vdd-io not found, using dummy regulator
[   11.635245] cs42l43 sdw:0:0:01fa:4243:01: supply vdd-cp not found, using dummy regulator
[   11.636538] sof-audio-pci-intel-lnl 0000:00:1f.3:  Topology file:     intel/sof-ipc4-tplg/sof-lnl-cs42l43-l0-4ch.tplg
[   11.638809] cs42l43 sdw:0:0:01fa:4243:01: devid: 0x042a43, rev: 0xa1, otp: 0x03
[   11.660408] cs42l43 sdw:0:0:01fa:4243:01: Slave 6 state check1: UNATTACHED, status was 1
[   11.842077] sof-audio-pci-intel-lnl 0000:00:1f.3: Booted firmware version: 2.13.0.1
[   23.125719] platform cs42l43-spi: deferred probe pending: cs42l43-spi: Failed to register SPI controller
[   23.125726] platform sof_sdw: deferred probe pending: sof_sdw: snd_soc_register_card failed -517

dmesg on working kernel (6.17.7)

[   10.336308] sof-audio-pci-intel-lnl 0000:00:1f.3: SoundWire enabled on CannonLake+ platform, using SOF driver
[   10.336455] sof-audio-pci-intel-lnl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040100
[   11.217384] sof-audio-pci-intel-lnl 0000:00:1f.3: bound 0000:00:02.0 (ops intel_audio_component_bind_ops [xe])
[   11.249712] sof-audio-pci-intel-lnl 0000:00:1f.3:  Topology file:     intel/sof-ipc4-tplg/sof-lnl-cs42l43-l0-4ch.tplg

No SPI controller error, sound card registers successfully.

SoundWire device status (on 6.17.8)

$ cat /sys/bus/soundwire/devices/*/status
Attached      # CS42L43 (sdw:0:0:01fa:4243:01)
UNATTACHED    # RT711 SDCA (sdw:0:0:025d:0711:01)

Analysis

Error -517 (EPROBE_DEFER) indicates sof_sdw is waiting for a dependency that never becomes ready. The root cause is cs42l43-spi failing to register its SPI controller, blocking the entire audio card registration.

This is a regression - same hardware, same distro config, same firmware. Only the kernel version changed.

Workaround

Downgrade to kernel 6.17.7

[charleskeepax]

Yeah, this is the offending commit:

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

Looking at getting a revert sent to stable, hopefully today. More details are on here: #5599

[charleskeepax]

The fix is merged in stable this can be closed.

[olib14]

Same issue on 6.17.9. After upgrading to 6.18.1 I see no change in functionality:

Looking at kernel sources, 6.17.y has the fix (_by_label), 6.18.y does not (_by_fwnode). There are further changes in master that I have have not tested but by appearance probably also does not work as it still ends up in _by_fwnode.

Of course, reverting to kernel 6.17.7 works.

[charleskeepax]

Yeah apologies about that, I am aware of that one. The "proper" fixes didn't make it in for 6.18 so we will need to push the same revert we did for 6.17 stable. However, when we did the last bits it was too early to push patches for 6.18 stable. I will get the patch pushed this week.