Re: [PATCH v3 2/2] soundwire: dmi-quirks: drop the ghost RT1320 on the Surface Pro 11 (Intel)

[Sergey Lebedev]

A second Surface Pro 11 (Intel) has reproduced the ghost independently and
confirms this patch removes it. The report is from leihua-dev on the
linux-surface tracker; I am relaying it here because it is a different unit with
a different BIOS from mine, and because this series has had no review of the code
since 2026-08-05.

Unit: Surface Pro for Business 11th Edition with Intel, SKU
Surface_Pro_11th_Edition_With_Intel_For_Business_2103, Core Ultra 7 266V, BIOS
17.100.143. Mine is the same SKU with a Core Ultra 7 268V and a different BIOS.

Before the quirk, both _ADRs present and ACPI enumerating each SDCA function
twice:

  acpi device:28: find_sdca_function: SDCA function SmartMic (type 3) at 0x2
  acpi device:29: find_sdca_function: SDCA function SmartAmp (type 1) at 0x4
  acpi device:2b: find_sdca_function: SDCA function SmartMic (type 3) at 0x2
  acpi device:2c: find_sdca_function: SDCA function SmartAmp (type 1) at 0x4

with sdw:0:0:025d:1320:00 permanently UNATTACHED. After the patch only the
2b/2c pair remains.

Their DMI_PRODUCT_SKU matches the quirk key exactly. That is the evidence I did
not have when I chose SKU over product-name matching in v2 — at the time it was
one machine and an argument.

Two limits on the report, stated so nobody has to discover them:

  - They run a 6.18 tree, so the dmi-quirks.c hunk was context-adapted; that
    branch has no ghost_realtek table yet. The logic is unchanged.

  - They applied five changes at once and did not bisect. That does not weaken
    this patch specifically: the duplicate _ADR and the doubled enumeration are
    both observable before any topology loads, and their before/after shows them
    changing.

Full report, with their kernel and userspace versions:
https://github.com/linux-surface/linux-surface/issues/1876#issuecomment-5470909030

Separately, one hazard that surfaced in the same comparison and may be worth
knowing on the list. Backporting a machine entry whose .sof_tplg_filename names a
dummy topology onto a pre-6.19 kernel yields no sound card at all — probe fails
with -ENOENT before anything registers, speakers included — because
225d70b80745 ("ASoC: SOF: don't check the existence of dummy topology") is not
there to skip the existence check. Upstream is fine: sof_test_topology_file()
tests the name and has no idea where the name came from, so from 6.19 a machine
entry and the generic path are treated alike. It is purely a backport hazard, and
it cost that reporter a boot with no audio at all.