From: Richard Fitzgerald <rf@opensource.cirrus.com> To: <vkoul@kernel.org>, <yung-chuan.liao@linux.intel.com>, <pierre-louis.bossart@linux.intel.com>, <sanyog.r.kale@intel.com> Cc: <alsa-devel@alsa-project.org>, <linux-kernel@vger.kernel.org>, <patches@opensource.cirrus.com>, Richard Fitzgerald <rf@opensource.cirrus.com> Subject: [PATCH 3/3] soundwire: bus: Fix lost UNATTACH when re-enumerating Date: Thu, 25 Aug 2022 13:22:41 +0100 [thread overview] Message-ID: <20220825122241.273090-4-rf@opensource.cirrus.com> (raw) In-Reply-To: <20220825122241.273090-1-rf@opensource.cirrus.com> Rearrange sdw_handle_slave_status() so that any peripherals on device #0 that are given a device ID are reported as unattached. The ensures that UNATTACH status is not lost. Handle unenumerated devices first and update the sdw_slave_status array to indicate IDs that must have become UNATTACHED. Look for UNATTACHED devices after this so we can pick up peripherals that were UNATTACHED in the original PING status and those that were still ATTACHED at the time of the PING but then reverted to unenumerated and were found by sdw_program_device_num(). As sdw_update_slave_status() is always processing a snapshot of a PING from some time in the past, it is possible that the status is changing while sdw_update_slave_status() is running. A peripheral could report attached in the PING, but detach and revert to device #0 and then be found in the loop in sdw_program_device_num(). Previously the code would not have updated slave->status to UNATTACHED because there was never a PING with that status. If the slave->status is not updated to UNATTACHED the next PING will report it as ATTACHED, but its slave->status is already ATTACHED so the re-attach will not be properly handled. This situations 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> --- drivers/soundwire/bus.c | 39 ++++++++++++++++++++++++++------------- 1 file changed, 26 insertions(+), 13 deletions(-) diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c index bb8ce26c68b3..1212148ac251 100644 --- a/drivers/soundwire/bus.c +++ b/drivers/soundwire/bus.c @@ -718,7 +718,8 @@ void sdw_extract_slave_id(struct sdw_bus *bus, } EXPORT_SYMBOL(sdw_extract_slave_id); -static int sdw_program_device_num(struct sdw_bus *bus) +static int sdw_program_device_num(struct sdw_bus *bus, + enum sdw_slave_status status[]) { u8 buf[SDW_NUM_DEV_ID_REGISTERS] = {0}; struct sdw_slave *slave, *_s; @@ -776,6 +777,12 @@ static int sdw_program_device_num(struct sdw_bus *bus) return ret; } + /* + * It could have dropped off the bus since the + * PING response so update the status array. + */ + status[slave->dev_num] = SDW_SLAVE_UNATTACHED; + break; } } @@ -1735,10 +1742,21 @@ int sdw_handle_slave_status(struct sdw_bus *bus, { enum sdw_slave_status prev_status; struct sdw_slave *slave; + bool programmed_dev_num = false; bool attached_initializing; int i, ret = 0; - /* first check if any Slaves fell off the bus */ + /* Handle any unenumerated peripherals */ + if (status[0] == SDW_SLAVE_ATTACHED) { + dev_dbg(bus->dev, "Slave attached, programming device number\n"); + ret = sdw_program_device_num(bus, status); + if (ret < 0) + dev_warn(bus->dev, "Slave attach failed: %d\n", ret); + + programmed_dev_num = true; + } + + /* Check if any fell off the bus */ for (i = 1; i <= SDW_MAX_DEVICES; i++) { mutex_lock(&bus->bus_lock); if (test_bit(i, bus->assigned) == false) { @@ -1764,17 +1782,12 @@ int sdw_handle_slave_status(struct sdw_bus *bus, } } - if (status[0] == SDW_SLAVE_ATTACHED) { - dev_dbg(bus->dev, "Slave attached, programming device number\n"); - ret = sdw_program_device_num(bus); - if (ret < 0) - dev_err(bus->dev, "Slave attach failed: %d\n", ret); - /* - * programming a device number will have side effects, - * so we deal with other devices at a later time - */ - return ret; - } + /* + * programming a device number will have side effects, + * so we deal with other devices at a later time + */ + if (programmed_dev_num) + return 0; /* Continue to check other slave statuses */ for (i = 1; i <= SDW_MAX_DEVICES; i++) { -- 2.30.2
WARNING: multiple messages have this Message-ID (diff)
From: Richard Fitzgerald <rf@opensource.cirrus.com> To: <vkoul@kernel.org>, <yung-chuan.liao@linux.intel.com>, <pierre-louis.bossart@linux.intel.com>, <sanyog.r.kale@intel.com> Cc: patches@opensource.cirrus.com, alsa-devel@alsa-project.org, Richard Fitzgerald <rf@opensource.cirrus.com>, linux-kernel@vger.kernel.org Subject: [PATCH 3/3] soundwire: bus: Fix lost UNATTACH when re-enumerating Date: Thu, 25 Aug 2022 13:22:41 +0100 [thread overview] Message-ID: <20220825122241.273090-4-rf@opensource.cirrus.com> (raw) In-Reply-To: <20220825122241.273090-1-rf@opensource.cirrus.com> Rearrange sdw_handle_slave_status() so that any peripherals on device #0 that are given a device ID are reported as unattached. The ensures that UNATTACH status is not lost. Handle unenumerated devices first and update the sdw_slave_status array to indicate IDs that must have become UNATTACHED. Look for UNATTACHED devices after this so we can pick up peripherals that were UNATTACHED in the original PING status and those that were still ATTACHED at the time of the PING but then reverted to unenumerated and were found by sdw_program_device_num(). As sdw_update_slave_status() is always processing a snapshot of a PING from some time in the past, it is possible that the status is changing while sdw_update_slave_status() is running. A peripheral could report attached in the PING, but detach and revert to device #0 and then be found in the loop in sdw_program_device_num(). Previously the code would not have updated slave->status to UNATTACHED because there was never a PING with that status. If the slave->status is not updated to UNATTACHED the next PING will report it as ATTACHED, but its slave->status is already ATTACHED so the re-attach will not be properly handled. This situations 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> --- drivers/soundwire/bus.c | 39 ++++++++++++++++++++++++++------------- 1 file changed, 26 insertions(+), 13 deletions(-) diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c index bb8ce26c68b3..1212148ac251 100644 --- a/drivers/soundwire/bus.c +++ b/drivers/soundwire/bus.c @@ -718,7 +718,8 @@ void sdw_extract_slave_id(struct sdw_bus *bus, } EXPORT_SYMBOL(sdw_extract_slave_id); -static int sdw_program_device_num(struct sdw_bus *bus) +static int sdw_program_device_num(struct sdw_bus *bus, + enum sdw_slave_status status[]) { u8 buf[SDW_NUM_DEV_ID_REGISTERS] = {0}; struct sdw_slave *slave, *_s; @@ -776,6 +777,12 @@ static int sdw_program_device_num(struct sdw_bus *bus) return ret; } + /* + * It could have dropped off the bus since the + * PING response so update the status array. + */ + status[slave->dev_num] = SDW_SLAVE_UNATTACHED; + break; } } @@ -1735,10 +1742,21 @@ int sdw_handle_slave_status(struct sdw_bus *bus, { enum sdw_slave_status prev_status; struct sdw_slave *slave; + bool programmed_dev_num = false; bool attached_initializing; int i, ret = 0; - /* first check if any Slaves fell off the bus */ + /* Handle any unenumerated peripherals */ + if (status[0] == SDW_SLAVE_ATTACHED) { + dev_dbg(bus->dev, "Slave attached, programming device number\n"); + ret = sdw_program_device_num(bus, status); + if (ret < 0) + dev_warn(bus->dev, "Slave attach failed: %d\n", ret); + + programmed_dev_num = true; + } + + /* Check if any fell off the bus */ for (i = 1; i <= SDW_MAX_DEVICES; i++) { mutex_lock(&bus->bus_lock); if (test_bit(i, bus->assigned) == false) { @@ -1764,17 +1782,12 @@ int sdw_handle_slave_status(struct sdw_bus *bus, } } - if (status[0] == SDW_SLAVE_ATTACHED) { - dev_dbg(bus->dev, "Slave attached, programming device number\n"); - ret = sdw_program_device_num(bus); - if (ret < 0) - dev_err(bus->dev, "Slave attach failed: %d\n", ret); - /* - * programming a device number will have side effects, - * so we deal with other devices at a later time - */ - return ret; - } + /* + * programming a device number will have side effects, + * so we deal with other devices at a later time + */ + if (programmed_dev_num) + return 0; /* Continue to check other slave statuses */ for (i = 1; i <= SDW_MAX_DEVICES; i++) { -- 2.30.2
next prev parent reply other threads:[~2022-08-25 12:23 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-08-25 12:22 [PATCH 0/3] soundwire: Fixes for spurious and missing UNATTACH Richard Fitzgerald 2022-08-25 12:22 ` Richard Fitzgerald 2022-08-25 12:22 ` [PATCH 1/3] soundwire: cadence: fix updating slave status when a bus has multiple peripherals Richard Fitzgerald 2022-08-25 12:22 ` Richard Fitzgerald 2022-08-25 12:57 ` Pierre-Louis Bossart 2022-08-25 12:57 ` Pierre-Louis Bossart 2022-08-25 12:22 ` [PATCH 2/3] soundwire: bus: Don't lose unattach notifications Richard Fitzgerald 2022-08-25 12:22 ` Richard Fitzgerald 2022-08-25 12:39 ` Pierre-Louis Bossart 2022-08-25 12:39 ` Pierre-Louis Bossart 2022-08-25 12:22 ` Richard Fitzgerald [this message] 2022-08-25 12:22 ` [PATCH 3/3] soundwire: bus: Fix lost UNATTACH when re-enumerating Richard Fitzgerald 2022-08-25 14:24 ` Pierre-Louis Bossart 2022-08-25 15:25 ` Richard Fitzgerald 2022-08-25 15:25 ` Richard Fitzgerald 2022-08-26 8:06 ` Pierre-Louis Bossart 2022-08-29 9:50 ` Richard Fitzgerald 2022-08-29 9:50 ` Richard Fitzgerald 2022-08-26 10:38 ` Richard Fitzgerald 2022-08-26 10:38 ` Richard Fitzgerald 2022-08-30 9:00 ` Richard Fitzgerald 2022-08-30 9:00 ` Richard Fitzgerald
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20220825122241.273090-4-rf@opensource.cirrus.com \ --to=rf@opensource.cirrus.com \ --cc=alsa-devel@alsa-project.org \ --cc=linux-kernel@vger.kernel.org \ --cc=patches@opensource.cirrus.com \ --cc=pierre-louis.bossart@linux.intel.com \ --cc=sanyog.r.kale@intel.com \ --cc=vkoul@kernel.org \ --cc=yung-chuan.liao@linux.intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.