Alder Lake-N (0x54c8), CHUWI GemiBook XPro: DSP reported disabled via PCI class code, blocking RT1308/SoundWire speaker amp

[alicekaggs]

Board

CHUWI GemiBook XPro (N100 / Alder Lake-N)
DMI: sys_vendor="CHUWI Innovation And Technology(ShenZhen)co.,Ltd",
product_name="GemiBook XPro", board_name="GemiBook XPro",
product_version="V1.05"

Kernel

Debian 13 (Trixie), tested identically on:

• 6.12.107+deb13-amd64
• 7.1.8+deb13-amd64

Audio hardware

00:1f.3 Audio device [0403]: Intel Corporation Alder Lake-N PCH High Definition
Audio Controller [8086:54c8] (prog-if 00 [HDA compatible], i.e. PCI class 0x040300)
Subsystem: Realtek Semiconductor Co., Ltd. Device [10ec:132c]

DSDT confirms a SoundWire-attached Realtek RT1308 smart amplifier
(ACPI _HID "10EC1308") under _SB.PC00.HDAS.IDA.SNDW, with a full
mipi-sdw-* property set and _STA hardcoded to 0x0F (always present).
Drivers for this (snd-soc-rt1308, snd-soc-rt1308-sdw, soundwire-intel,
soundwire-bus, soundwire-cadence) are present in the stock Debian
kernel package but never load, because SoundWire enumeration is never
reached in the first place (see below).

Symptom

dmesg shows the SOF PCI driver aborting immediately, before any
SoundWire/codec enumeration happens:

sof-audio-pci-intel-tgl 0000:00:1f.3: enabling device (0000 -> 0002)
sof-audio-pci-intel-tgl 0000:00:1f.3: the DSP is not enabled on this platform, aborting probe

aplay -l shows zero cards for internal audio. dmesg | grep -i soundwire
is completely empty (not an error - the SoundWire bus driver never
attempts a scan at all).

Confirmed via strings on the installed .ko.xz that this exact message
originates in snd-sof-intel-hda-generic.ko, not in
sound/hda/intel-dsp-config.c.

What's been ruled out

1. snd_intel_dspcfg.dsp_driver=3 via kernel cmdline - confirmed applied
   (/sys/module/snd_intel_dspcfg/parameters/dsp_driver reads 3), but
   the identical abort still occurs. Since this override is consulted
   in intel-dsp-config.c but the abort originates in hda-generic.c
   instead, the two appear to be independent gates.
2. Attempted to flip the PCI class code via setpci -s 0000:00:1f.3 0x09.b=0x80 (0x040300 -> 0x040380) to test whether the class-code
   report was software-writable. The write did not persist (read back
   as 0x00 / unchanged) - this appears to be a genuine firmware-locked
   hardware report, not a soft-strapped value.
3. No BIOS/UEFI setting related to audio/DSP/SoundWire is exposed on
   this board (checked all visible menus, no hidden advanced menu
   found via common unlock key combos).
4. Tested on two kernel versions six months apart (6.12.107, 7.1.8) -
   identical result, ruling out a stale-kernel issue.

Notes

Per the mailing list, condition (a) for SOF activation is "the DSP
needs to be enabled (as reported by the pci class info)". This board's
audio controller reports PCI class 0x040300 (no DSP, legacy only),
which appears to be a genuine firmware-level report rather than a
software table gap - despite the board's real hardware (SoundWire +
RT1308 amp, confirmed via DSDT) requiring the DSP path to function.

If this is indeed a firmware-locked flag, please let me know -
otherwise happy to test any patches or provide additional ACPI/dmesg
dumps.