All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jisheng Zhang" <jszhang@kernel.org>
Cc: linux-i3c@lists.infradead.org,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	Frank.Li@kernel.org
Subject: Re: [PATCH] i3c: dw: use COMMAND_PORT_TRANSFER_ARG instead of hardcoding
Date: Thu, 13 Aug 2026 05:10:34 +0000	[thread overview]
Message-ID: <20260813051034.F2D511F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260813044225.22237-1-jszhang@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing check for the transfer error status and timeout in `dw_i3c_master_daa()` leads to incorrectly registering ghost devices on an empty bus or upon hardware failure.
--

--- Patch [1]: [PATCH] i3c: dw: use COMMAND_PORT_TRANSFER_ARG instead of hardcoding ---
commit 22998f6bbcb44d600e23cd17f1e6c5b48d268e31
Author: Jisheng Zhang <jszhang@kernel.org>

i3c: dw: use COMMAND_PORT_TRANSFER_ARG instead of hardcoding

This commit replaces the hardcoded value 1 with the well defined
COMMAND_PORT_TRANSFER_ARG macro.

> diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i3c-master.c
> index 405089f181c4d..7038aa3bf4c7d 100644
> --- a/drivers/i3c/master/dw-i3c-master.c
> +++ b/drivers/i3c/master/dw-i3c-master.c
> @@ -921,7 +921,7 @@ static int dw_i3c_master_daa(struct i3c_master_controller *m)
>  		goto rpm_out;
>  	}
>  	cmd = &xfer->cmds[0];
> -	cmd->cmd_hi = 0x1;
> +	cmd->cmd_hi = COMMAND_PORT_TRANSFER_ARG;
>  	cmd->cmd_lo = COMMAND_PORT_DEV_COUNT(master->maxdevs - pos) |
>  		      COMMAND_PORT_DEV_INDEX(pos) |
>  		      COMMAND_PORT_CMD(I3C_CCC_ENTDAA) |

[ ... ]

>  	dw_i3c_master_enqueue_xfer(master, xfer);
>  	if (!wait_for_completion_timeout(&xfer->comp, XFER_TIMEOUT))
>  		dw_i3c_master_dequeue_xfer(master, xfer);
>  
>  	/*
>  	 * cmd->rx_len holds the number of addresses ENTDAA left unassigned.
>  	 * On an empty bus rx_len == maxdevs, so avoid GENMASK(-1, 0).
>  	 */
>  	if (cmd->rx_len >= master->maxdevs)
>  		newdevs = 0;
>  	else
>  		newdevs = GENMASK(master->maxdevs - cmd->rx_len - 1, 0);

[Severity: High]
This is a pre-existing issue, but I noticed a potential problem in how
transfer errors and timeouts are handled here in dw_i3c_master_daa().

If wait_for_completion_timeout() times out due to a noisy or unresponsive
I3C bus, the completion timeout and any hardware transfer errors appear to
be ignored.

In a timeout scenario, cmd->rx_len remains 0. The code then falls through
and calculates newdevs = GENMASK(...) using that zero value.

Could this cause the driver to incorrectly interpret the timeout as a
successful discovery of devices for all free slots, leading it to register
phantom devices?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260813044225.22237-1-jszhang@kernel.org?part=1

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

  reply	other threads:[~2026-08-13  5:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-13  4:42 [PATCH] i3c: dw: use COMMAND_PORT_TRANSFER_ARG instead of hardcoding Jisheng Zhang
2026-08-13  4:42 ` Jisheng Zhang
2026-08-13  5:10 ` sashiko-bot [this message]
2026-08-13 20:40 ` Frank Li
2026-08-13 20:40   ` Frank Li

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=20260813051034.F2D511F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=alexandre.belloni@bootlin.com \
    --cc=jszhang@kernel.org \
    --cc=linux-i3c@lists.infradead.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.