Re: [PATCH v2 0/2] ASoC: fix audio on the Microsoft Surface Pro 11 (Intel)

[Sergey Lebedev]

Some context I should have gathered before v1, not after v2. None of it
needs action from you; it is here so nobody spends time twice.

1. An overlapping series is already on the list
-----------------------------------------------

Amaan Lalani sent this on 2026-08-28, two days before my v2:

  [PATCH 0/2] ASoC: fix SoundWire enumeration on Surface Pro 11
  https://lore.kernel.org/linux-sound/BY5PR02MB63701A05A58EF6B4D6CAAC31A0AC2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/

Same machine, and in substance the same two changes as my v1 2/3 and 3/3 -
the name-prefix reuse for _ADR entries differing only in class id, and an
is_peripheral_attached() test on SDW_SLAVE_UNATTACHED. So the review you
already gave me applies to it unchanged: it detects the ghost at runtime
rather than removing it at enumeration.

Their version is better than mine was in two respects worth keeping if that
approach is ever preferred: it hooks both asoc_sdw_count_sdw_endpoints() and
asoc_sdw_parse_sdw_endpoints() rather than only the parse path, and it
carries Fixes: tags.

2. There is a body of downstream work for this machine
------------------------------------------------------

André Gilerson has carried Surface Pro 11 Intel patches in a linux-surface
fork since February - audio, cameras, an IR sensor driver, touchpad, lid
wake, a suspend hang fix. People have been running them daily for months.
None of it has been submitted here.

  https://github.com/linux-surface/linux-surface/pull/1990

His audio fix takes the traditional shape: a DMI-gated machine entry in
soc-acpi-intel-lnl-match.c naming the real peripheral outright, with
name_prefix "rt1320-1" and two endpoints. With such an entry matched, the
generic find_acpi_adr_device() path is never reached, so the ghost never
gets the chance to consume an amp index.

3. The part that is actually interesting: the generic path is better here
--------------------------------------------------------------------------

Measured on this machine today, with v2 applied, stock alsa-ucm-conf
1.2.15.3 and firmware-sof 2025.12.2, and no local configuration:

  Components: 'HDA:80862820,80860101,00100000  cfg-amp:1
               iec61937-pcm:7,6,5 spk:rt1320 mic:rt1320-1 cfg-mics:1'

  Using function topologies instead intel/sof-ipc4-tplg/sof-lnl-dummy.tplg
  loading topology 0: intel/sof-ipc4-tplg/sof-sdca-1amp-id2.tplg
  loading topology 1: intel/sof-ipc4-tplg/sof-sdca-mic-id4.tplg
  loading topology 2: intel/sof-ipc4-tplg/sof-hdmi-pcm5-id5.tplg

  arecord -l: card 0: sofsoundwire, device 4: Microphone

With no machine entry, the generic path uses a *-dummy.tplg base, dispatches
the function topologies itself, and produces cfg-mics:1.

On the machine-entry branches the microphone is a recurring problem. Users
report the mic missing entirely on the 6.18 branch - sof-sdca-mic-id4.tplg
present in firmware but never requested - and the v7.0 commit fixes it by
switching to a dummy base and forcing "Playback-SmartAmp" /
"Capture-SmartMic" dailink names, which is the dispatcher's own behaviour
reimplemented by hand. Its commit message attributes the loss to the
monolithic base topology discarding the SmartMic function. Separately, the
missing cfg-mics breaks the UCM import outright on alsa-ucm-conf 1.2.16.

I have not run that branch here, so that comparison is their reports against
my measurements rather than one machine tested both ways. I have offered to
do exactly that on this device and will report the result.

If it holds, the general shape is worth more than this laptop: remove ghost
_ADRs at enumeration and let the generic path do its job, instead of adding
a match entry per model - which for this hardware appears to cost the
microphone. Surface Pro 12 (Panther Lake) is reported to have the same
firmware shape, so it would be the next test of that idea rather than the
next entry.

Thanks,
Sergey