Re: [PATCH v3 00/10] Expand SoundWire enumeration helper coverage

[Charles Keepax]

On Fri, Jun 19, 2026 at 03:41:44PM +0200, Pierre-Louis Bossart wrote:
> 
> > The patch series in [1] added a new helper to remove common boiler plate
> > waiting for a device to enumerate on SoundWire, however, many devices
> > also wait for enumeration during probe. This series updates things to be
> > suitable such that we can call the same helper at probe time when the
> > unattach_request is not valid.
> 
> So if we are no longer testing for unattach_request, should this be definition and its use be removed?
> Looks like there were multiple evolutions since the initial patch
> "soundwire: sdw_slave: track unattach_request to handle all init sequences",
> is an additional cleanup needed?

There are still a couple of end drivers that use unattach_request
to attempt to track if the device was reset. I suspect that is
likely better done other ways but its very hard stuff to change
without detailed knowledge of the specific devices.

I think our only part still using this is cs42l42 which I think
someone has the power to test internally, so we could look at
that at some point in the future. But I am not comfortable
changing the realtek or ess parts using this myself.

> > There is one final step outstanding which is to add a core helper
> > that waits for a device to drop off the bus. This is not include
> > in this series and should be the last step of this process.
> 
> Humm, I am not following why the core needs to wait for a device
> to drop off.  If there's a bus reset or device reset, it's almost
> immediate.  It the devices loses sync then the core wouldn't
> wait either since it's not expecting the device to drop-off.

The problem is mostly from the device side. This usually comes up
from a device reset. So the driver does a reset, device drops off
the bus, the device driver doesn't want to carry on until it
knows the device is back on the bus. So naively one calls
sdw_slave_wait_for_init() but there is nothing the ensures the
core saw the bus disconnection before that call so it might
immediately succeed, causing the driver to attempt to access a
missing device.

Yeah the fall of the bus is fast but so are processors, you need
to actually ensure you can't shortcut the wait. Although typing
this it occurs to me it probably doesn't have to be a wait one
can probably just manually reinit the initalization_complete
completion. But hopefully I will get this series ready soon and
we can discuss on there.

Thanks,
Charles