On 9/7/22 10:52, Richard Fitzgerald wrote:
Don't re-enumerate a peripheral on #0 until we have seen and handled an UNATTACHED notification for that peripheral.
Without this, it is possible for the UNATTACHED status to be missed and so the slave->status remains at ATTACHED. If slave->status never changes to UNATTACHED the child driver will never be notified of the UNATTACH, and the code in sdw_handle_slave_status() will skip the second part of enumeration because the slave->status has not changed.
This scenario can happen because PINGs are handled in a workqueue function which is working from a snapshot of an old PING, and there is no guarantee when this function will run.
A peripheral could report attached in the PING being handled by sdw_handle_slave_status(), but has since reverted to device #0 and is then found in the loop in sdw_program_device_num(). Previously the code would not have updated slave->status to UNATTACHED because it had not yet handled a PING where that peripheral had UNATTACHED.
This situation happens fairly frequently with multiple peripherals on a bus that are intentionally reset (for example after downloading firmware).
Signed-off-by: Richard Fitzgerald rf@opensource.cirrus.com
Reviewed-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com
drivers/soundwire/bus.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c index 1cc858b4107d..6e569a875a9b 100644 --- a/drivers/soundwire/bus.c +++ b/drivers/soundwire/bus.c @@ -773,6 +773,16 @@ static int sdw_program_device_num(struct sdw_bus *bus) if (sdw_compare_devid(slave, id) == 0) { found = true;
/** To prevent skipping state-machine stages don't* program a device until we've seen it UNATTACH.* Must return here because no other device on #0* can be detected until this one has been* assigned a device ID.*/if (slave->status != SDW_SLAVE_UNATTACHED)return 0;/* * Assign a new dev_num to this Slave and * not mark it present. It will be marked