Hi all,

I'm hitting a persistent CS42L43 SDCA reattach timeout on a Dell XPS 14
(Panther Lake) that I haven't been able to clear via any software means. Audio 
worked correctly for several days after Arch Linux (with CachyOS kernel) 
install, then stopped without any change in hardware, kernel version or audio-
related software stack and has not recovered since across multiple kernels and 
distributions.

Hardware:
- Dell XPS 14 (DA14260) with Intel Panther Lake
- Audio: CS42L43 (link 0) + CS35L57 (links 2, 3)
- PCI audio: Intel 8086:e428, Dell SSID 1028:0db9
- BIOS: 1.3.1 dated 2026-02-12

Reproduced on:
- linux-cachyos 7.0.1 and 7.0.3
- Fedora Rawhide (current daily, kernel 7.1-rc1)

Symptom: 
- dmesg at boot: sdca_class sdw:0:0:01fa:4245:01: timed out waiting for device 
re-attach
- no ALSA card is created. SOF probe ultimately fails. CS35L57 amps on
links 2 and 3 seem to enumerate cleanly; only the CS42L43 on link 0 seems to 
fail to complete the reattach handshake.

What does NOT recover the chip:
- Reboot (warm or cold)
- Kernel downgrade to the initial 7.0.1
- Cold power cycle (>60s power button hold, >5min off-state, no AC)
- BIOS (or, rather, UEFI) settings reset to factory defaults
- Boot Windows 11 (with Cirrus driver loaded, audio fully working
  in Windows), clean shutdown, then boot Linux

What confirms hardware is functional:
- Dell SupportAssist firmware-level audio diagnostic plays clear tones
  on all speakers
- Windows 11 with Cirrus driver yields a fully functional soundcard

Debug log attached: dmesg with snd_soc_sdca.dyndbg=+p
soundwire_bus.dyndbg=+p soundwire_intel.dyndbg=+p

Notable observations from the debug log:
- CS42L43 enumerates and "probe complete" succeeds
- soundwire_intel.link.0 reports "first link up, programming SYNCPRD"
- After that, no further activity on link 0 — no "Slave attached,
  programming device number" event
- 5s later, the SDCA reattach times out
- CS35L57 amps on links 2/3 complete the full enumeration sequence

Possibly relevant (secondary) bug:
A kernel oops is reproducible on demand by running
"modprobe -r snd_sof_pci_intel_ptl". Stack trace shows NULL deref in
sdca_dev_unregister_functions during cleanup of an incompletely-probed
device. Oops log attached separately. Whether this is related to
the persistent reattach failure or a separate issue, I'm not sure.

Attached: 
1. dmesg with snd_soc_sdca.dyndbg=+p soundwire_bus.dyndbg=+p
soundwire_intel.dyndbg=+p showing CS42L43 enumeration completing but reattach
timing out
2. Earlier kernel oops after "modprobe -r snd_sof_pci_intel_ptl" for 
additional context (may be relevant to a secondary bug in 
snd_soc_sdca cleanup, but is not the primary issue here as the audio failure 
occurred independently of the oops in subsequent boots).
3. Output from alsa-info.sh
4. lspci -nnvv output

I'm happy to test patches, capture additional logs, or run any debug
builds. Hardware is reproducibly stuck so any patch can be verified
quickly.

Thanks,
Tobias