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

[Charles Keepax <ckeepax@opensource.cirrus.com>]

On Mon, Jun 22, 2026 at 11:44:01AM +0200, Pierre-Louis Bossart wrote:
> On 6/19/26 18:07, Charles Keepax wrote:
> > On Fri, Jun 19, 2026 at 03:41:44PM +0200, Pierre-Louis Bossart wrote:
> > 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.
> 
> Don't we already have the interface to detect a device was UNATTACHED?
> In theory the core will invoke the update_status() callback on
> every status change. Each driver would use the information to
> know when the UNATTACHED happened and likewise when the device
> is enumerated/initialized again. So far most drivers just return
> and do nothing when an UNATTACHED status is reported.

Yeah so update_status() is the normal mechanism for a driver to
know if it becomes unattached AFAIK. Indeed what this is working
up to is removing the code in cs42l43 that uses that to track if
the device is attached. Although also now you can also use the
intialization_complete completion for this purpose too, since it
was moved to complete_all().

> The only thing we can't control at the moment is that when
> a device reports as device0, the core will enumerate it and
> attempt to initialize it. If additional time is needed prior
> to the enumeration, we don't have the hooks for it - that would
> not be quite standard behavior anyways.

Its not really about additional time, there is always time,
events in the real world are not instant.

Thread 1 (driver)                 Thread 2 (core)
-----------------                 ---------------
Reset device
call wait_for_init()
                                  reinit_completion()

You need something to ensure that wait_for_init() doesn't skip
the completion before the core calls reinit_completion(). Or are
you saying there is already a mechanism that prevents this that I
am missing?

Thanks,
Charles