Re: [PATCH 0/3] ASoC/soundwire: remove ghost peripherals from the mach table

[Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>]

On 9/15/26 15:13, Bard Liao wrote:
> ACPI may report a ghost SoundWire peripheral. It will cause unexpected
> error like duplicated links, codec driver can't probe, etc. This series
> check the presence of SoundWire peripherals and skip the non-existing
> peripherals.

I am afraid this raises quite a few opens, such as the 'mockup' support
and delayed enumeration.

A better way to only deal with actual codecs would be to only probe
codec drivers when the codecs report as ATTACHED and get enumerated,
instead of during the ACPI parsing stage.
This is a solution that was discussed a ong time ago, probably circa
2016, during one of the LPC miniconferences, and the direction from
maintainers was that the probe could be used to enable resources (power,
gpio, clocks) that might be required for the hardware codec to become
functional and report as ATTACHED. That's the reason why the probe is
done on all codecs exposed in ACPI, even 'ghost' ones, with an
update_status() callback to the codec driver when the presence of that
codec is detected on the bus.

In practice I am not aware of any codec drivers doing anything with
power/gpio/clocks in the probe stages, at least for ACPI platforms, so
it may be a good time to revisit this direction. SDCA class drivers do
exactly what I described, the subdevices are registered only upon
enumeration, not during ACPI parsing. It's a much simpler design with a
lot fewer potential races.

Problems:
- this would be a very invasive change to sdw_slave_add(), with the
device_register() skipped and moved to the enumeration stage. It'd have
to be opt-in and used only a newer platforms to avoid breaking the
'legacy' devices.
- there is still *nothing* that would tell you that all codec hardware
on a given platform completed the enumeration. You could have a fixed
delay but this would need to be large enough to cover all cases and that
could make the platform boot slower than the current solution - not ideal.

Another option would be to parse the ACPI0018 device, which describes
audio endpoints and makes references to codecs, which could be used to
filter out 'ghost' codecs that don't provide any endpoints. The spec for
this ACPI0018 is not public but could be reverse-engineered from Windows
platforms. The main benefit is that this filtering could be done in the
ACPI parsing stages and not change anything in the probe and startup
sequences.