[BUG] ASUS ROG Zephyrus G14 GU405AR (Panther Lake, 1043:15d4): CS42L43 keyboard speakers absent from playback

[ondrej-skyba]

Summary

On the ASUS ROG Zephyrus G14 GU405AR, normal Linux speaker playback reaches
only the two bottom-facing speakers driven by the CS35L56 amplifiers on
SoundWire link 2. The two speakers beside the keyboard, driven through the
CS42L43 on SoundWire link 3, remain silent.

A direct CS42L43 internal tone-generator test produced a clearly audible 2 kHz
tone from the keyboard-side speakers, so the codec output, wiring, and speakers
are functional. The missing piece appears to be the machine quirk and normal
playback topology/routing.

This happens on every boot and with every normal playback application.

System

Distribution: Ubuntu 26.04 LTS
Kernel: 7.0.0-28-generic (7.0.0-28.28)
linux-firmware: 20260319.git217ca6e4.1ubuntu
alsa-ucm-conf: 1.2.15.3-1ubuntu1.4
PipeWire: 1.6.2-1ubuntu1.1
WirePlumber: 0.5.13-1ubuntu1

sys_vendor=ASUS
product_name=ROG Zephyrus G14 GU405AR
product_version=1.0
board_vendor=ASUSTeK COMPUTER INC.
board_name=GU405AR
board_version=1.0

00:1f.3 Multimedia audio controller [0401]:
Intel Corporation Panther Lake Smart Sound Technology BUS [8086:e328]
Subsystem: ASUSTeK Computer Inc. Device [1043:15d4]
Kernel driver in use: sof-audio-pci-intel-ptl

SoundWire devices:

link 2:
  sdw:0:2:01fa:3556:01:0  CS35L56
  sdw:0:2:01fa:3556:01:1  CS35L56

link 3:
  sdw:0:3:01fa:4243:01    CS42L43

Default boot

The default quirk resolves to 0x1, and the kernel loads:

intel/sof-ipc4-tplg/sof-ptl-cs42l43-agg-l3-cs35l56-l2.tplg

The sound card, bottom speakers, headphone path, and microphone work, but the
CS42L43 keyboard-side speakers are absent from normal playback.

Clean-boot test with SOC_SDW_CODEC_SPKR

I performed a one-shot clean boot with:

snd_soc_sof_sdw.quirk=32768

The card registered successfully:

sof_sdw sof_sdw: Overriding quirk 0x1 => 0x8000
sof_sdw sof_sdw: Setting CS42L43 Speaker volume limit to 128

The CS42L43 speaker controls and DAI appeared:

cs42l43 Speaker Digital: Playback [on]
cs42l43 Speaker L Input 1: DP6RX1
cs42l43 Speaker R Input 1: DP6RX2

However, when both AMP1 Speaker and AMP2 Speaker (the bottom CS35L56
amplifiers) were muted, normal Speaker PCM playback was completely silent.
Thus enabling SOC_SDW_CODEC_SPKR exposes the codec speaker path but the loaded
topology still does not carry normal Speaker PCM to CS42L43 DP6.

Four-channel topology test

The firmware package also provides:

intel/sof-ipc4-tplg/sof-ptl-cs42l43-agg-l3-cs35l56-l2-4ch.tplg

A clean boot with the codec-speaker quirk and that topology failed to register
the card:

snd_soc_sof_sdw.quirk=32768
snd_sof.tplg_filename=sof-ptl-cs42l43-agg-l3-cs35l56-l2-4ch.tplg

Relevant log:

sof-audio-pci-intel-ptl 0000:00:1f.3: DMICs detected in NHLT tables: 0
sof-audio-pci-intel-ptl 0000:00:1f.3: error: can't connect DAI dai-copier.DMIC.dmic01.capture stream dmic01
sof-audio-pci-intel-ptl 0000:00:1f.3: failed to add widget type 28 name : dai-copier.DMIC.dmic01.capture stream dmic01
sof_sdw sof_sdw: ASoC: topology: could not load header: -22
sof_sdw sof_sdw: error -EINVAL: snd_soc_register_card failed -22

This machine reports no PCH DMIC and uses the CS42L43 microphone path. The
available -4ch.tplg therefore does not match its microphone wiring.

Expected behavior / likely work needed

Normal Speaker PCM should drive both the two CS35L56 bottom speakers and the
CS42L43 keyboard-side speakers, while retaining the working CS42L43 microphone
path.

The upstream sof_sdw_ssid_quirk_table currently has no entry for ASUS
1043:15d4. Based on the clean-boot test, this machine likely needs:

1. an SSID/DMI quirk enabling SOC_SDW_CODEC_SPKR; and
2. a topology/function-topology route that sends the normal speaker stream to
   both the CS35L56 pair and CS42L43 DP6 without requiring PCH DMIC.dmic01.

There may also need to be UCM handling to unmute cs42l43 Speaker Digital
automatically once the kernel/topology route exists.

Related issue

#5759 concerns a Zephyrus G16 with the same Panther Lake link layout, but it has
a different model/subsystem (GU606AP, 1043:1634) and a different topology
selection problem. The maintainer closed it after upstream changes and invited
a new issue if problems remained. This GU405AR still reproduces the issue on
kernel 7.0 and has no matching SSID quirk.

Disclaimer

Yes, this issue was fully written by AI as well as investigated on my local PC, concretely GPT 5.6-sol on extra high reasoning, as I would personally never be able to investigate or describe the issue in such detail. I hope it proves useful.