### 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 omacom/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 #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 #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.