summaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorRichard Fitzgerald <rf@opensource.cirrus.com>2022-09-14 19:02:46 +0300
committerVinod Koul <vkoul@kernel.org>2022-09-20 07:59:31 +0300
commit7297f8fa9a4312701c5066cd0d22e1a252cbb2d7 (patch)
tree67d2f71c84b4e834bf9b666d53570c0e5cce41fe /README
parentf605f32e59d8021a032746c2ca73b1adc46873d7 (diff)
downloadlinux-7297f8fa9a4312701c5066cd0d22e1a252cbb2d7.tar.xz
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 <rf@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20220914160248.1047627-4-rf@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions