sof_sdw probe fails with -ENOMEM on ASUS Zenbook S14 UX5406AA (Panther Lake): duplicate SDW3-Playback-SimpleJack from duplicated ACPI audio controller object

[ajblack75-dotcom]

Follow-up to #5721 (closed) on the same machine. The original monolithic-topology
ABI failure is gone on current kernels, but sof_sdw now fails earlier, during card
construction, before any topology file is read.

@bardliao @charleskeepax - this may be the concrete ACPI evidence you were looking
for in #5721 regarding the phantom Realtek device.

System

Machine: ASUS Zenbook S14 UX5406AA
CPU: Intel Core Ultra 7 356H (Panther Lake)
BIOS: UX5406AA.300 (2025-12-18)
OS: Arch Linux
Kernel: 7.1.5
Audio PCI: 0000:00:1f.3 (sof-audio-pci-intel-ptl)
SOF firmware: 2.14.1.1

SoundWire devices

sdw:0:1:01fa:3556:01:2   cs35l56
sdw:0:1:01fa:3556:01:3   cs35l56
sdw:0:2:01fa:3556:01:0   cs35l56
sdw:0:2:01fa:3556:01:1   cs35l56
sdw:0:3:01fa:4243:01     cs42l43
sdw:0:3:025d:0722:01     rt722   <-- not physically present

All four CS35L56 and the CS42L43 probe successfully.

Failure

[    6.135817] sof-audio-pci-intel-ptl 0000:00:1f.3: No SoundWire machine driver found for the ACPI-reported configuration:
[    6.144109] sof-audio-pci-intel-ptl 0000:00:1f.3: link 1 mfg_id 0x01fa part_id 0x3556 version 0x3
[    6.144111] sof-audio-pci-intel-ptl 0000:00:1f.3: link 1 mfg_id 0x01fa part_id 0x3556 version 0x3
[    6.144112] sof-audio-pci-intel-ptl 0000:00:1f.3: link 2 mfg_id 0x01fa part_id 0x3556 version 0x3
[    6.144113] sof-audio-pci-intel-ptl 0000:00:1f.3: link 2 mfg_id 0x01fa part_id 0x3556 version 0x3
[    6.144114] sof-audio-pci-intel-ptl 0000:00:1f.3: link 3 mfg_id 0x01fa part_id 0x4243 version 0x3
[    6.144115] sof-audio-pci-intel-ptl 0000:00:1f.3: link 3 mfg_id 0x025d part_id 0x0722 version 0x3
[    6.144122] sof-audio-pci-intel-ptl 0000:00:1f.3: Use SoundWire default machine driver with function topologies
[    6.145517] sof-audio-pci-intel-ptl 0000:00:1f.3:  Topology file:     function topologies
[    6.428108] sof-audio-pci-intel-ptl 0000:00:1f.3: Booted firmware version: 2.14.1.1
[    6.438134] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:1f.3/sof_sdw/SDW3-Playback-SimpleJack'
[    6.438375]  mc_probe+0xb4b/0x14e0 [snd_soc_sof_sdw]
[    6.438421]  ? __pfx_sof_sdw_driver_init+0x10/0x10 [snd_soc_sof_sdw]
[    6.438664] sof_sdw sof_sdw: probe with driver sof_sdw failed with error -12

cat /proc/asound/cards -> --- no soundcards ---

Root cause

ACPI enumerates duplicate SDCA functions on SoundWire link 3:

[    5.746103] acpi device:3f: SDCA function SmartMic (type 3) at 0x2
[    5.746106] acpi device:40: SDCA function UAJ (type 6) at 0x3
[    5.746108] acpi device:41: SDCA function HID (type 10) at 0x4
[    5.746182] acpi device:45: SDCA function UAJ (type 6) at 0x1
[    5.746184] acpi device:46: SDCA function SmartMic (type 3) at 0x2
[    5.746186] acpi device:47: SDCA function HID (type 10) at 0x3
[    5.746189] acpi device:48: SDCA function SmartAmp (type 1) at 0x4

Two UAJ, two SmartMic and two HID functions on the same link. Both UAJ functions
produce the DAI link name "SDW3-Playback-SimpleJack", and sysfs rejects the second
registration, aborting mc_probe.

The duplication appears to originate in the DSDT itself. The kernel flags it as a
firmware bug during early boot:

[    0.375196] ACPI BIOS Error (bug): Failure creating named object [\_SB.AUDC], AE_ALREADY_EXISTS (20251212/dswload2-326)
[    0.375208] ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20251212/psobject-220)

The audio controller object _SB.AUDC is declared twice. The phantom rt722 on link 3
and its duplicate function set follow from this.

Workarounds attempted

1. blacklist snd_soc_rt722_sdca
   Removes the duplicate-name failure, but ACPI still reports the device, so sof_sdw
   builds a DAI link for a codec component that can never register:

   platform sof_sdw: deferred probe pending: sof_sdw: snd_soc_register_card failed -517
   

   Permanent EPROBE_DEFER, still no card.

2. snd_sof.disable_function_topology=1
   Confirmed applied (/sys/module/snd_sof/parameters/disable_function_topology = Y),
   no effect. The machine-table lookup finds no entry for this configuration, so the
   generic SDCA machine driver is used regardless, and the failure is in mc_probe
   before any topology is loaded.

3. snd_sof.tplg_filename=
   Not applicable for the same reason - failure precedes topology load.

Note for anyone landing here from older reports: tplg_filename and
disable_function_topology are parameters of snd_sof, not snd_sof_pci_intel_ptl.
Passing them to the PCI module is silently ignored:

snd_sof_pci_intel_ptl: unknown parameter 'tplg_filename' ignored

What seems to be needed

Either dedupe of DAI link names in the generic SDCA machine driver when ACPI reports
multiple functions of the same type on one link, or an SDCA quirk that ignores the
phantom rt722 (0x025d:0x0722) on this platform.

dmesg.txt

acpidump-ux5406aa.txt

[Cymirk]

#5837
check this out!

[bardliao]

@ajblack75-dotcom Please share the DMI information. It is likely that we need to add your DMI information to adr_remap_quirk_table[] like https://github.com/thesofproject/linux/blob/topic/sof-dev/drivers/soundwire/dmi-quirks.c#L191

[ajblack75-dotcom]

@bardliao Here is the DMI info, serial numbers and UUID redacted.

BIOS Vendor:        American Megatrends International, LLC.
BIOS Version:       UX5406AA.303
BIOS Release Date:  02/09/2026

System Manufacturer:  ASUS
System Product Name:  Zenbook S14 UX5406AA
System Version:       1.0
System Family:        Zenbook S14
System SKU Number:    (empty)

Board Manufacturer:   ASUSTeK COMPUTER INC.
Board Product Name:   UX5406AA
Board Version:        1.0

Worth noting for the quirk table: DMI_SYS_VENDOR is "ASUS" on this machine, not
"ASUSTeK COMPUTER INC.". The ASUSTeK string only appears in DMI_BOARD_VENDOR.

DMI_BOARD_NAME is "UX5406AA", which is probably the more stable match across SKUs -
this model ships with several CPU bins (mine is a Core Ultra 7 356H, the reporter of
#5721 has a Core Ultra 9 386H) and DMI_PRODUCT_NAME carries the marketing name.

One correction to the issue body above: I have since updated firmware, so the BIOS
version is UX5406AA.303 (2026-02-09) rather than UX5406AA.300 (2025-12-18) as
originally posted. The failure is identical on both.

For reference, the ADRs involved on link 3:

sdw:0:3:01fa:4243:01    cs42l43   (real)
sdw:0:3:025d:0722:01    rt722     (not physically present)

Let me know if you want an acpidump or anything else. Happy to test a patch.