Dell XPS 13 DX13260 (1028:0e53): no sound at all after dell-xps13-sidecar-amps workaround — CS35L56 firmware never downloads despite blobs being present

[MBvisti]

System details

• Dell XPS 13 DX13260 (Wildcat Lake), DMI product SKU 0E53, audio subsystem 1028:0e53
• Omarchy 4.0.2-1 (stable channel)
• linux 7.1.9.arch1-2
• dell-xps13-sidecar-amps 1.0.0-2 (the workaround merged in Add Dell XPS 13 sidecar amplifier workaround omarchy-pkgs#150)
• linux-firmware-cirrus 20260810-2
• limine-mkinitcpio-hook 1.37.1-1, mkinitcpio 41.1-1

What's wrong?

After installing the official dell-xps13-sidecar-amps workaround (options snd_soc_sof_sdw quirk=65536) and rebooting, the internal speakers produce no sound at all. Before the workaround I had the "thin, no-bass" tweeter-only output described in #7427; after it, complete silence from the sof-soundwire Speaker sink (sink present, default, unmuted, volume 1.00).

Steps to reproduce:

1. Install the edge package dell-xps13-sidecar-amps (drops /usr/lib/modprobe.d/dell-xps13-sidecar-amps.conf with quirk=65536) and reboot.
2. Play audio to the sof-soundwire Speaker sink (card 0, device 2).
3. Result: no output at all; both CS35L56 amps bind but never download their tuning firmware.

Kernel log (boot after the workaround):

cs35l56 spi-cs35l56-left:  Cirrus Logic CS35L56 Rev B2 OTP1 fw:4.2.1 (patched=0)
cs35l56 spi-cs35l56-right: Cirrus Logic CS35L56 Rev B2 OTP1 fw:4.2.1 (patched=0)
...
cs35l56 spi-cs35l56-left:  DSP1: Firmware: 1a00d6 vendor: 0x2 v4.2.1, 42 algorithms
cs35l56 spi-cs35l56-right: DSP1: Firmware: 1a00d6 vendor: 0x2 v4.2.1, 42 algorithms
cs35l56 spi-cs35l56-left:  FIRMWARE_MISSING
cs35l56 spi-cs35l56-left:  Calibration disabled due to missing firmware controls
cs35l56 spi-cs35l56-left:  Can't read tuning IDs
cs35l56 spi-cs35l56-right: FIRMWARE_MISSING
cs35l56 spi-cs35l56-right: Calibration disabled due to missing firmware controls
cs35l56 spi-cs35l56-right: Can't read tuning IDs

The firmware the driver should load is present on this system, so this is not the "blobs missing" case:

/usr/lib/firmware/cirrus/cs35l56-b2-dsp1-misc-10280e53-spkid1.wmfw.zst
/usr/lib/firmware/cirrus/cs35l56-b2-dsp1-misc-10280e53-spkid1-ampl.bin.zst
/usr/lib/firmware/cirrus/cs35l56-b2-dsp1-misc-10280e53-spkid1-ampr.bin.zst
(also spkid2 and spkid3 variants; package: linux-firmware-cirrus 20260810-2)

Yet the driver never reports loading cs35l56-b2-dsp1-misc-10280e53-*.wmfw (no DSP1: cirrus/...wmfw: line in the log), the DSP1 firmware line still shows the OTP v4.2.1 instead of the 0e53 wmfw's v4.5.9, and the amps end up muted. Compare the expected/validated result in #7427 (7.1.8):

cs35l56 spi-cs35l56-right: DSP1: cirrus/cs35l56-b2-dsp1-misc-10280e53-spkid1.wmfw: format 3 timestamp 0x68d1a788
cs35l56 spi-cs35l56-right: DSP1: Firmware: 1a01d6 vendor: 0x2 v4.5.9, 42 algorithms
...
cs35l56 spi-cs35l56-right: DSP1: cirrus/cs35l56-b2-dsp1-misc-10280e53-spkid1-ampr.bin (v1): v4.5.9
...
cs35l56 spi-cs35l56-right: Calibration applied
cs35l56 spi-cs35l56-right: Tuning PID: 0x112481, SID: 0x352112, TID: 0x342200

Observations / hunches:

• Hardware enablement (amps binding, quirk=65536 taking effect) works exactly as in Enable Dell XPS 13 sidecar speaker amplifiers #7032 / omarchy-pkgs#150. The failure is that the CS35L56 driver does not download the present per-SKU firmware on this kernel.
• The validated test in Dell XPS 13 (0E53) has no bass: CS35L56 woofer amps never load firmware without the sof_sdw sidecar quirk #7427 was on 7.1.8; this machine runs 7.1.9.arch1-2. Worth checking the cs35l56/sof_sdw delta between 7.1.8 and 7.1.9 (including the Dell SSIDExV2/spkid selection logic, and whether the requested firmware name now includes a suffix such as spkid0 or a variant that has no matching file).
• Per the Cirrus docs, on this topology (CS42L43 on SoundWire → CS35L56 on SPI) the amps are mute until their wmfw is downloaded, and the CS35L56 DSP also serves as the crossover — so a firmware-load failure produces total silence, not just missing bass. That matches the symptom.

Since quirk=65536 only enables hardware that then cannot finish firmware download, the packaged workaround is effectively unusable on this configuration. Happy to run further diagnostics (full omarchy-debug requires an interactive TTY/sudo, which I don't have in this session) or test the same kernel-level checks on 7.1.8 to confirm whether this is a 7.1.9 regression.