Re: [PATCH 2/3] ASoC: sdw_utils: skip endpoints of a peripheral that is not on the bus

[Sergey Lebedev <lsa.uz@pm.me>]

Sorry for the long silence - I did not have access to the hardware until
now. Thank you both for the review; it changed the shape of the fix for
the better.

> > Why not just remove SWRA from the BIOS?
>
> Or add a quirk in drivers/soundwire/dmi-quirks.c to skip this SWRA
> device entirely, this has been the direction so far to ignore 'ghost'
> devices.
>
> It's much safer IMHO than trying to detect if a device is physically
> present or not.

Agreed, and it works. I have tested it on the machine and it is good
enough: one quirk replaces both 2/3 and 3/3, so v2 is two patches
instead of three, and nothing has to guess at runtime whether a device
is present.

With the ghost's _ADR remapped to zero, sdw_acpi_find_slaves() never
creates the peripheral:

  # ls /sys/bus/soundwire/devices/
  sdw-master-0-0
  sdw:0:0:025d:1320:01        <- only the real one now

and everything downstream falls out:

  - amplifier is named "rt1320-1", so the stock sof-soundwire UCM
    profile addresses the device that is actually there
  - no -EEXIST, no -61 link startup errors, card registers cleanly
  - 4 playback + 1 capture, speakers audible, internal mic captures
  - no local UCM, PipeWire or WirePlumber configuration

On the BIOS question: the firmware is Microsoft's, signed, and updated
through Windows Update. The defect is present in the current November
2025 bundle and on every unit shipped so far, so I have no way to have
SWRA removed at the source.

> Not sure if it is the case, but it is possible that the SKU has
> different rt1320 versions depending on when was the device
> manufactured. Hope they use different SKU values with different
> rt1320 versions.

Good point, and it is a real hazard: the remap keys on the full 64-bit
_ADR, whose version nibble is part of the match. A batch with a
different RT1320 version would not match - harmless - but if such a
batch ever reported class 0 as the real part, a name-keyed quirk would
remove the working device and leave the ghost.

v2 therefore matches on the product SKU rather than the product name,
following dell_sku_0A3E above it:

  DMI_MATCH(DMI_SYS_VENDOR, "Microsoft Corporation"),
  DMI_EXACT_MATCH(DMI_PRODUCT_SKU,
                  "Surface_Pro_11th_Edition_With_Intel_For_Business_2103")

That keeps the remap to the hardware it was verified on. If other SKUs
turn out to need it, they can be added as they are reported, which is
also how we would find out whether the versions do differ.

On the other review point, for completeness:

> Not sure if it is true. AFAIK, Realtek has a few codecs with the same
> part ID and different class ID and they are different codecs.

Understood - and it no longer matters, because the patch that assumed
otherwise is dropped in v2. The quirk claims nothing general about class
ids; it says only that on this SKU this specific _ADR is a ghost, which
is the one thing I have actually verified.

One correction I owe you, because I told you the opposite in the v1
cover letter. About the DAI link name collision I had written a fourth
patch for and then dropped, I said:

  "With 2/3 applied the phantom's endpoints never reach the naming code,
   so that collision is no longer reachable on this machine and we
   cannot demonstrate it."

That was wrong. While testing v2 I had a boot where the quirk did not
take effect, and the machine failed exactly there:

  sysfs: cannot create duplicate filename
    '/devices/pci0000:00/0000:00:1f.3/sof_sdw/SDW0-Capture-SmartMic'
  kobject_add_internal failed for SDW0-Capture-SmartMic with -EEXIST,
    don't try to register things with the same name in the same directory
  sof_sdw sof_sdw: probe with driver sof_sdw failed with error -12

So the collision is reachable, reproducible and fatal whenever a ghost
declaring a duplicate function reaches create_sdw_dailink(). The quirk
does not fix that; it only removes this particular ghost before the
naming code sees it. create_sdw_dailink() still builds names from link
id and function type alone, so any board with two peripherals of the
same function type on one link would hit it.

I have not included a fix in v2 - with the quirk applied I cannot
reproduce it on purpose any more, and I would rather not send an
untestable patch. If you would like it addressed, I am happy to send it
separately and to describe the failure in more detail.

Testing note for v2: verified on 7.0.0-30 (Ubuntu 26.04), with the quirk
backported, because that is the kernel this machine runs. The posted
patch is against thesofproject/linux topic/sof-dev; the table entry is
identical and the mechanism it relies on is unchanged between the two
trees - slave.c drops a peripheral whose overridden _ADR is zero in
both. 1/2 is byte-identical to v1's 1/3 and unchanged since it was
tested on 7.1.0-rc7.

v2 follows this message.

Thanks again,
Sergey