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

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

On 6/22/26 12:16, Charles Keepax wrote:
> 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?

Ah ok I see what you are trying to do.
I am afraid we don't have a mechanism to do what your Thread1 describes, but you could alternatively have a less sequential mechanism where you only do the reset, and then the rest of the initialization is done in the update_status() callback. Your Thread1 would be implemented in two disjoint parts with no need for waiting.

The completions were meant for the suspend/resume cases mostly. I am not sure we want to use completion or any other synchronization between core and peripheral driver, it'd be introducing even more races.

Anyways, best to follow-up with next series, my comments are speculative and probably somewhat off-track..