All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Vijendar Mukunda" <Vijendar.Mukunda@amd.com>
Cc: linux-sound@vger.kernel.org
Subject: Re: [PATCH v5 10/25] soundwire: amd: return response on IMM status cleanup timeout
Date: Sat, 07 Nov 2026 16:04:47 +0000	[thread overview]
Message-ID: <sashiko-outbox-203016@kernel.org> (raw)
In-Reply-To: <20261107154659.3358223-11-Vijendar.Mukunda@amd.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [High] soundwire: amd: unpolled IMM_RES_VALID clear in
  amd_sdw_send_cmd_get_resp()
--

commit 89df36f0150dc3c96912a2aa097eb2d1d5dc0e6d
Author: Vijendar Mukunda <Vijendar.Mukunda@amd.com>

soundwire: amd: return response on IMM status cleanup timeout

This commit changes amd_sdw_send_cmd_get_resp() to log a warning, write
*response, and return 0 when polling for AMD_SDW_IMM_RES_VALID to clear
times out after reading the response registers.

> diff --git a/drivers/soundwire/amd_manager.c b/drivers/soundwire/amd_manager.c
> index f2ed0490aa82d..579b12946c0ca 100644
> --- a/drivers/soundwire/amd_manager.c
> +++ b/drivers/soundwire/amd_manager.c
> @@ -384,9 +384,12 @@ static int amd_sdw_send_cmd_get_resp(struct amd_sdw_manager *amd_manager, u32 lo
>  	ret = readl_poll_timeout(amd_manager->mmio + ACP_SW_IMM_CMD_STS, sts,
>  				 !(sts & AMD_SDW_IMM_RES_VALID), ACP_DELAY_US, AMD_SDW_TIMEOUT);
>  	if (ret) {
> -		dev_err(amd_manager->dev, "SDW%x cmd status retry failed\n",
> -			amd_manager->instance);
> -		return ret;
> +		/* Response already latched above; timeout here is non-fatal.
> +		 * The residual IMM_RES_VALID bit will be cleared by the bad-state
> +		 * guard on the next invocation, provided IMM_CMD_BUSY is not also stuck.
> +		 */
> +		dev_warn(amd_manager->dev, "SDW%x cmd status retry failed\n",
> +			 amd_manager->instance);
>  	}
>  	*response = ((u64)upper_resp << 32) | lower_resp;
>  	return 0;

[Severity: High]
Can returning 0 when AMD_SDW_IMM_RES_VALID fails to clear cause the next
command to read stale response registers from ACP_SW_IMM_RESP_UPPER_WORD
and ACP_SW_IMM_RESP_LOWER_QWORD?

When a caller such as amd_sdw_xfer_msg() issues back-to-back commands, the
next call to amd_sdw_send_cmd_get_resp() hits the bad-state guard, which
writes AMD_SDW_IMM_RES_VALID without polling for it to clear before
issuing the new command and polling for (sts & AMD_SDW_IMM_RES_VALID):

drivers/soundwire/amd_manager.c:amd_sdw_send_cmd_get_resp() {
    ...
	if (sts & AMD_SDW_IMM_RES_VALID) {
		dev_err(amd_manager->dev, "SDW%x manager is in bad state\n", amd_manager->instance);
		writel(AMD_SDW_IMM_RES_VALID, amd_manager->mmio + ACP_SW_IMM_CMD_STS);
	}
	writel(upper_data, amd_manager->mmio + ACP_SW_IMM_CMD_UPPER_WORD);
	writel(lower_data, amd_manager->mmio + ACP_SW_IMM_CMD_LOWER_QWORD);

	ret = readl_poll_timeout(amd_manager->mmio + ACP_SW_IMM_CMD_STS, sts,
				 (sts & AMD_SDW_IMM_RES_VALID), ACP_DELAY_US, AMD_SDW_TIMEOUT);
    ...
}

Because readl_poll_timeout() reads ACP_SW_IMM_CMD_STS immediately before
sleeping and the clear handshake is asynchronous, the residual
AMD_SDW_IMM_RES_VALID bit can still be set on the first read, causing
amd_sdw_send_cmd_get_resp() to return the previous command's response
before the new SoundWire frame finishes on the bus.  Follow-up commit
"soundwire: amd: clarify bad-state guard poll omission in IMM_RES_VALID
path" documents the missing poll in the bad-state guard, but does not
prevent the subsequent response poll from matching the un-cleared bit.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261107154659.3358223-1-Vijendar.Mukunda@amd.com?part=10

  reply	other threads:[~2026-11-07 16:04 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-07 15:45 [PATCH v5 00/25] soundwire: amd: SoundWire manager driver bug fixes Vijendar Mukunda
2026-11-07 15:45 ` [PATCH v5 01/25] soundwire: amd: consolidate pad register macros into amd_init.h Vijendar Mukunda
2026-11-07 15:45 ` [PATCH v5 02/25] soundwire: amd: program pad SCHMEN and OE control for ACP 7.0/7.1/7.2 Vijendar Mukunda
2026-11-07 16:13   ` sashiko-bot
2026-11-07 19:00     ` Mukunda,Vijendar
2026-11-07 15:45 ` [PATCH v5 03/25] soundwire: amd: add pad ctrl helpers for D0/D3 PM transitions Vijendar Mukunda
2026-11-07 15:45 ` [PATCH v5 04/25] soundwire: amd: track full pad teardown across suspend/resume Vijendar Mukunda
2026-11-07 15:45 ` [PATCH v5 05/25] soundwire: amd: fix missing wake interrupt and group wake-arming calls in runtime suspend Vijendar Mukunda
2026-11-07 16:04   ` sashiko-bot
2026-11-07 15:45 ` [PATCH v5 06/25] soundwire: amd: fix IRQ thread dropping STATUS_0TO7 on simultaneous wake Vijendar Mukunda
2026-11-07 15:45 ` [PATCH v5 07/25] soundwire: amd: remove STATUS_8TO11 clear from amd_sdw_process_wake_event() Vijendar Mukunda
2026-11-07 15:45 ` [PATCH v5 08/25] soundwire: amd: fix missing wake interrupt for ACP6.3 in POWER_OFF suspend Vijendar Mukunda
2026-11-07 16:02   ` sashiko-bot
2026-11-07 15:45 ` [PATCH v5 09/25] soundwire: amd: fix SDW command timeout return value handling Vijendar Mukunda
2026-11-07 15:45 ` [PATCH v5 10/25] soundwire: amd: return response on IMM status cleanup timeout Vijendar Mukunda
2026-11-07 16:04   ` sashiko-bot [this message]
2026-11-07 15:45 ` [PATCH v5 11/25] soundwire: amd: clarify bad-state guard poll omission in IMM_RES_VALID path Vijendar Mukunda
2026-11-07 15:45 ` [PATCH v5 12/25] soundwire: amd: cache ping slave status to avoid spurious disconnect on timeout Vijendar Mukunda
2026-11-07 15:45 ` [PATCH v5 13/25] soundwire: amd: assert msg_lock is held in amd_sdw_read_ping_status() Vijendar Mukunda
2026-11-07 15:45 ` [PATCH v5 14/25] soundwire: amd: fix work drain ordering in remove path Vijendar Mukunda
2026-11-07 16:14   ` sashiko-bot
2026-11-07 19:07     ` Mukunda,Vijendar
2026-11-07 15:45 ` [PATCH v5 15/25] soundwire: amd: defer dev_set_drvdata() until after INIT_WORK() Vijendar Mukunda
2026-11-07 15:45 ` [PATCH v5 16/25] soundwire: amd: pm_runtime guard in remove path Vijendar Mukunda
2026-11-07 16:10   ` sashiko-bot
2026-11-07 15:45 ` [PATCH v5 17/25] soundwire: amd: use interrupt_enabled flag to guard IRQ work scheduling Vijendar Mukunda
2026-11-07 16:21   ` sashiko-bot
2026-11-07 20:29     ` Mukunda,Vijendar
2026-11-07 15:45 ` [PATCH v5 18/25] soundwire: amd: delay *sdw_ctx publication until after startup succeeds Vijendar Mukunda
2026-11-07 16:15   ` sashiko-bot
2026-11-07 20:19     ` Mukunda,Vijendar
2026-11-07 15:45 ` [PATCH v5 19/25] soundwire: amd: propagate amd_init_sdw_manager() error on resume Vijendar Mukunda
2026-11-07 15:45 ` [PATCH v5 20/25] soundwire: amd: drop amd_deinit_sdw_manager() in POWER_OFF suspend Vijendar Mukunda
2026-11-07 15:45 ` [PATCH v5 21/25] soundwire: amd: replace >= ACP70 with explicit switch/case in PM paths Vijendar Mukunda
2026-11-07 15:45 ` [PATCH v5 22/25] soundwire: amd: fix interrupt gate and work drain ordering in PM ops Vijendar Mukunda
2026-11-07 16:25   ` sashiko-bot
2026-11-07 20:37     ` Mukunda,Vijendar
2026-11-07 15:45 ` [PATCH v5 23/25] soundwire: amd: check for NULL manager drvdata in sdw_amd_startup() Vijendar Mukunda
2026-11-07 15:45 ` [PATCH v5 24/25] soundwire: amd: fix shared-register RMW race in amd_sdw_set_device_state() Vijendar Mukunda
2026-11-07 15:45 ` [PATCH v5 25/25] soundwire: amd: fix shared-register RMW race in amd_sdw_host_wake_enable() Vijendar Mukunda

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=sashiko-outbox-203016@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Vijendar.Mukunda@amd.com \
    --cc=linux-sound@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.