aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/stackcollapse.py
diff options
context:
space:
mode:
authorRichard Fitzgerald <[email protected]>2022-09-14 17:02:46 +0100
committerVinod Koul <[email protected]>2022-09-20 10:29:31 +0530
commit7297f8fa9a4312701c5066cd0d22e1a252cbb2d7 (patch)
tree67d2f71c84b4e834bf9b666d53570c0e5cce41fe /tools/perf/scripts/python/stackcollapse.py
parentf605f32e59d8021a032746c2ca73b1adc46873d7 (diff)
soundwire: bus: Don't re-enumerate before status is UNATTACHED
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 <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions