New data point: this failure is reliably triggered by booting Linux directly
after a Windows session, and cannot be recovered from within Linux. I think
it points at the dummy VSPK regulator rather than a timing race.
ASUS Zenbook 14 UX3405MA, BIOS UX3405MA.311, SSID 10431A63, Ubuntu 26.04,
with `options snd_hda_scodec_cs35l41 firmware_autostart=0` in place.
Across six boots, PUP_DONE failures track the preceding OS, not the
kernel:
boot kernel date PUP_DONE RTC clock step
-5 7.0.0-31-generic 2026-09-10 0 none
-4 7.0.0-31-generic 2026-09-11 0 none
-3 7.0.0-31-generic 2026-09-18 0 none
-2 7.0.0-34-generic 2026-09-25 0 none
-1 7.0.0-34-generic 2026-10-01 16 -7199 s
0 7.0.0-34-generic 2026-10-01 0 none
The -7199 s step on boot -1 is chronyd correcting an RTC that Windows had
written in local time, so it independently confirms Windows ran immediately
before that boot. Boot -2 ran the same 7.0.0-34 kernel cleanly, which rules
out a kernel regression.
On the failing boot both amps enumerate and bind normally:
cs35l41-hda spi0-CSC3551:00-cs35l41-hda.0: CS35L41 Bound - SSID: 10431A63,
BST: 1, VSPK: 1, CH: L, FW EN: 0, SPKID: 1
cs35l41-hda spi0-CSC3551:00-cs35l41-hda.1: CS35L41 Bound - SSID: 10431A63,
BST: 1, VSPK: 0, CH: R, FW EN: 0, SPKID: 1
then every power-up attempt times out on both:
cs35l41-hda spi0-CSC3551:00-cs35l41-hda.0: Failed waiting for
CS35L41_PUP_DONE_MASK: -110
cs35l41-hda spi0-CSC3551:00-cs35l41-hda.1: Failed waiting for
CS35L41_PUP_DONE_MASK: -110
The state is latched for the entire boot. Those 16 failures span the initial
probe, userspace bringing the sink up, a resume from suspend, and a
deliberate cold open of the PCM device (fully released first --
/proc/asound/card0/pcm0p/sub0/status = "closed") which does trigger a real
fresh power-up attempt and fails identically. Both amps report
power/control=on and runtime_status=active throughout: powered and
addressable over SPI, but never asserting PUP_DONE. Everything upstream is
healthy (SOF running, ALC294 DACs show "Converter: stream=1", sink default
and unmuted) -- the amps are the only broken link.
A warm reboot does not clear it; a full power-off for ~10-15 s does.
Disabling Windows Fast Startup (powercfg /h off) prevents recurrence.
Interpretation: Windows drives these amps with real firmware and appears to
leave the VSPK rail / shared RESET line latched on the way out. Since VSPK
for this SSID is backed by a dummy regulator, regulator_enable() is a no-op,
so there is no code path by which Linux can cycle that rail -- the driver
cannot recover a rail it never controlled, and the condition persists until
the hardware loses power. The latched hardware state is my inference; the
correlation and the non-recoverability are measured.
If the VSPK GPIO (pin 72 / 0x48) were described as a proper fixed GPIO
regulator in cs35l41-hda-property.c for SSID 10431A63, I would expect the
driver to recover without a power cycle -- in this case and in the original
runtime-PM case this bug was filed for.
Happy to test a patch or gather further logs.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2154681
Title:
cs35l41-hda: SSID 10431A63 (ASUS Zenbook 14 UX3405MA) speakers silent
— PUP_DONE_MASK -110 on runtime power cycle due to missing VSPK GPIO
regulator
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2154681/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
