From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Richard Fitzgerald <rf@opensource.cirrus.com>,
vkoul@kernel.org, yung-chuan.liao@linux.intel.com,
sanyog.r.kale@intel.com
Cc: patches@opensource.cirrus.com, alsa-devel@alsa-project.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 5/5] soundwire: bus: Don't exit early if no device IDs were programmed
Date: Wed, 14 Sep 2022 15:58:02 +0200 [thread overview]
Message-ID: <3b51ec11-772c-3263-46f8-a32ccd4b89b9@linux.intel.com> (raw)
In-Reply-To: <20220914120949.747951-6-rf@opensource.cirrus.com>
On 9/14/22 14:09, Richard Fitzgerald wrote:
> Only exit sdw_handle_slave_status() right after calling
> sdw_program_device_num() if it actually programmed an ID into at
> least one device.
>
> sdw_handle_slave_status() should protect itself against phantom
> device #0 ATTACHED indications. In that case there is no actual
> device still on #0. The early exit relies on there being a status
> change to ATTACHED on the reprogrammed device to trigger another
> call to sdw_handle_slave_status() which will then handle the status
> of all peripherals. If no device was actually programmed with an
> ID there won't be a new ATTACHED indication. This can lead to the
> status of other peripherals not being handled.
>
> The status passed to sdw_handle_slave_status() is obviously always
> from a point of time in the past, and may indicate accumulated
> unhandled events (depending how the bus manager operates). It's
> possible that a device ID is reprogrammed but the last PING status
> captured state just before that, when it was still reporting on
> ID #0. Then sdw_handle_slave_status() is called with this PING info,
> just before a new PING status is available showing it now on its new
> ID. So sdw_handle_slave_status() will receive a phantom report of a
> device on #0, but it will not find one.
>
> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Nice work, thanks Richard
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
> ---
> drivers/soundwire/bus.c | 29 +++++++++++++++++++++--------
> 1 file changed, 21 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
> index 6e569a875a9b..8eded1a55227 100644
> --- a/drivers/soundwire/bus.c
> +++ b/drivers/soundwire/bus.c
> @@ -729,7 +729,7 @@ 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, bool *programmed)
> {
> u8 buf[SDW_NUM_DEV_ID_REGISTERS] = {0};
> struct sdw_slave *slave, *_s;
> @@ -739,6 +739,8 @@ static int sdw_program_device_num(struct sdw_bus *bus)
> int count = 0, ret;
> u64 addr;
>
> + *programmed = false;
> +
> /* No Slave, so use raw xfer api */
> ret = sdw_fill_msg(&msg, NULL, SDW_SCP_DEVID_0,
> SDW_NUM_DEV_ID_REGISTERS, 0, SDW_MSG_FLAG_READ, buf);
> @@ -797,6 +799,8 @@ static int sdw_program_device_num(struct sdw_bus *bus)
> return ret;
> }
>
> + *programmed = true;
> +
> break;
> }
> }
> @@ -1756,7 +1760,7 @@ int sdw_handle_slave_status(struct sdw_bus *bus,
> {
> enum sdw_slave_status prev_status;
> struct sdw_slave *slave;
> - bool attached_initializing;
> + bool attached_initializing, id_programmed;
> int i, ret = 0;
>
> /* first check if any Slaves fell off the bus */
> @@ -1787,14 +1791,23 @@ 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
> + * Programming a device number will have side effects,
> + * so we deal with other devices at a later time.
> + * This relies on those devices reporting ATTACHED, which will
> + * trigger another call to this function. This will only
> + * happen if at least one device ID was programmed.
> + * Error returns from sdw_program_device_num() are currently
> + * ignored because there's no useful recovery that can be done.
> + * Returning the error here could result in the current status
> + * of other devices not being handled, because if no device IDs
> + * were programmed there's nothing to guarantee a status change
> + * to trigger another call to this function.
> */
> - return ret;
> + sdw_program_device_num(bus, &id_programmed);
> + if (id_programmed)
> + return 0;
> }
>
> /* Continue to check other slave statuses */
next prev parent reply other threads:[~2022-09-14 14:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-14 12:09 [PATCH v3 0/5] soundwire: Fixes for spurious and missing UNATTACH Richard Fitzgerald
2022-09-14 12:09 ` Richard Fitzgerald
2022-09-14 12:09 ` [PATCH v3 1/5] soundwire: cadence: fix updating slave status when a bus has multiple peripherals Richard Fitzgerald
2022-09-14 12:09 ` Richard Fitzgerald
2022-09-14 12:09 ` [PATCH v3 2/5] soundwire: bus: Don't lose unattach notifications Richard Fitzgerald
2022-09-14 12:09 ` Richard Fitzgerald
2022-09-14 12:09 ` [PATCH v3 3/5] soundwire: bus: Don't re-enumerate before status is UNATTACHED Richard Fitzgerald
2022-09-14 12:09 ` Richard Fitzgerald
2022-09-14 12:09 ` [PATCH v3 4/5] soundwire: cadence: Fix lost ATTACHED interrupts when enumerating Richard Fitzgerald
2022-09-14 12:09 ` Richard Fitzgerald
2022-09-14 13:48 ` Pierre-Louis Bossart
2022-09-14 14:30 ` Richard Fitzgerald
2022-09-14 14:30 ` Richard Fitzgerald
2022-09-14 12:09 ` [PATCH v3 5/5] soundwire: bus: Don't exit early if no device IDs were programmed Richard Fitzgerald
2022-09-14 12:09 ` Richard Fitzgerald
2022-09-14 13:58 ` Pierre-Louis Bossart [this message]
2022-09-14 14:00 ` [PATCH v3 0/5] soundwire: Fixes for spurious and missing UNATTACH Pierre-Louis Bossart
2022-09-14 14:00 ` Pierre-Louis Bossart
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=3b51ec11-772c-3263-46f8-a32ccd4b89b9@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@opensource.cirrus.com \
--cc=rf@opensource.cirrus.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: link
Be 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.