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

[Liao, Bard]

> -----Original Message-----
> From: Liao, Bard
> Sent: Wednesday, September 16, 2026 12:08 PM
> To: 'Pierre-Louis Bossart' <pierre-louis.bossart@xxxxxxxxx>; Bard Liao <yung-
> chuan.liao@xxxxxxxxxxxxxxx>; linux-sound@xxxxxxxxxxxxxxx; vkoul@xxxxxxxxxx;
> broonie@xxxxxxxxxx; tiwai@xxxxxxx
> Cc: vinod.koul@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> peter.ujfalusi@xxxxxxxxxxxxxxx
> Subject: RE: [PATCH 0/3] ASoC/soundwire: remove ghost peripherals from the
> mach table
> 
> 
> 
> > -----Original Message-----
> > From: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxx>
> > Sent: Wednesday, September 16, 2026 3:09 AM
> > To: Bard Liao <yung-chuan.liao@xxxxxxxxxxxxxxx>; linux-
> > sound@xxxxxxxxxxxxxxx; vkoul@xxxxxxxxxx; broonie@xxxxxxxxxx;
> > tiwai@xxxxxxx
> > Cc: vinod.koul@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> > peter.ujfalusi@xxxxxxxxxxxxxxx; Liao, Bard <bard.liao@xxxxxxxxx>
> > Subject: Re: [PATCH 0/3] ASoC/soundwire: remove ghost peripherals from
> the
> > mach table
> >
> > 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.
> 
> The mockup support will not change. We will only check the existance if
> no mach item matched. And we can always add the mochup configurations to
> the mach table.
> And indeed, it will add a little delay in some cases. However, based on
> our test, only about 1 ms delay will be added.
> 
> >
> > 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.
> 
> But this doesn't solve our issue. The DAI link will still be created
> and the sound card will not probe because the codec driver doesn't probe.
> Our target is that the ghost device should not be added in the DAI link.
> So that the sound card can probe properly.
> 
> > 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.
> 
> I didn't change sdw_slave_add(). All the change in SoundWire driver is to
> add a flag and a completion to share the information of whether the
> enumeration of the bus is completed.
> 

Hi Pierre,

Do you still have any concerns about this series?
Or maybe I can add a module parameter to disable the feature?

> > - 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.
> 
> Yeah, I set a 3 sec timeout. I believe that is large enough. And the flag
> and the completion is to avoid the meaningless waiting. With the
> is_present flag, we can ensure a bus will not be waiting for more than 1
> time. And with the enumeration_complete completion, we won't wait for the
> ghost device to be enumerated.
> 
> >
> > 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.
> 
> Is ACPI0018 reliable? Will it still list the ghost device? The ghost rt722
> has all endpoints listed in its DisCo table