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

[Pierre-Louis Bossart]

On 6/19/26 18:07, Charles Keepax wrote:
> 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.

ok, it looks like a more difficult change than a basic cleanup.

> 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.

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.

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.