From: sashiko-bot@kernel.org
To: tze.yee.ng@altera.com
Cc: linux-i3c@lists.infradead.org, Frank.Li@kernel.org, imx@lists.linux.dev
Subject: Re: [PATCH v4 3/3] i3c: master: Validate GET CCC payload length and retry Direct GET once
Date: Tue, 30 Jun 2026 13:41:48 +0000 [thread overview]
Message-ID: <20260630134148.C281F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <1bc55d123df33e2e66ad58ccbc17ba20f74999fe.1782824628.git.tze.yee.ng@altera.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The Renesas I3C driver fails to set `rx_count` on completion, forcing `actual_len` to 0 and failing all GET CCC validations
- [Low] Dead code in `i3c_master_getstatus_locked()` due to missed update from `len` to `actual_len`
- [Low] The payload validation function evaluates a mathematically impossible and redundant condition
--
commit 3c7b45c2572b29be23202a83e0e0241b82a602bb
Author: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com>
i3c: master: Validate GET CCC payload length and retry Direct GET once
This commit adds optional_bytes to struct i3c_ccc_cmd_payload to describe
variable-length GET CCC responses and validates payload lengths in
i3c_master_send_ccc_cmd_locked(). It also retries failed Direct GET CCCs
and updates I3C master drivers to set actual_len on successful GET transfers.
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index f1be38a640ca1..5741c3f80ed58 100644
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c
[ ... ]
> +static int i3c_ccc_validate_payload_len(struct i3c_ccc_cmd *cmd)
> +{
> + unsigned int i;
> +
> + if (!cmd->rnw)
> + return 0;
> +
> + for (i = 0; i < cmd->ndests; i++) {
> + struct i3c_ccc_cmd_payload *p = &cmd->dests[i].payload;
> + u16 min_len;
> +
> + if (p->optional_bytes > p->len)
> + return -EINVAL;
> +
> + if (p->actual_len > p->len)
> + return -EIO;
> +
> + if (!p->len)
> + continue;
> +
> + min_len = p->len - p->optional_bytes;
> + if (p->actual_len < min_len ||
> + (!p->optional_bytes && p->actual_len != p->len))
> + return -EIO;
> + }
> +
> + return 0;
> +}
[Severity: Low]
Does this evaluate a redundant condition? Since p->actual_len > p->len is
already caught above, when !p->optional_bytes is true, min_len equals
p->len. The left side of the OR captures all cases where actual_len < len.
The right side is only evaluated if actual_len == len, making
actual_len != p->len always false.
> @@ -1409,7 +1473,7 @@ static int i3c_master_getmwl_locked(struct i3c_master_controller *master,
> if (ret)
> goto out;
>
> - if (dest.payload.len != sizeof(*mwl)) {
> + if (dest.payload.actual_len != sizeof(*mwl)) {
> ret = -EIO;
> goto out;
> }
[Severity: Low]
Was i3c_master_getstatus_locked() missed in these updates?
This patch changes drivers to write the received payload length to
actual_len instead of modifying len, but i3c_master_getstatus_locked()
still checks the unmodified length:
drivers/i3c/master.c:i3c_master_getstatus_locked() {
...
if (dest.payload.len != sizeof(*getstatus)) {
ret = -EIO;
goto out;
}
...
}
Since len is initialized to sizeof(*getstatus) and is no longer modified
by the drivers, does this make the error path unreachable dead code?
> diff --git a/drivers/i3c/master/renesas-i3c.c b/drivers/i3c/master/renesas-i3c.c
> index f39c449922ca2..fec614700843f 100644
> --- a/drivers/i3c/master/renesas-i3c.c
> +++ b/drivers/i3c/master/renesas-i3c.c
> @@ -805,6 +805,8 @@ static int renesas_i3c_send_ccc_cmd(struct i3c_master_controller *m,
> ret = xfer->ret;
> if (ret)
> ccc->err = I3C_ERROR_M2;
> + else if (ccc->rnw)
> + ccc->dests[0].payload.actual_len = cmd->rx_count;
>
> return ret;
> }
[Severity: High]
Can this cause all GET CCC operations to fail on this hardware?
This code assigns cmd->rx_count to actual_len, but it appears
cmd->rx_count is never incremented during
I3C_INTERNAL_STATE_CONTROLLER_COMMAND_READ.
Looking at renesas_i3c_resp_isr():
if (NDBSTLV0_RDBLV(renesas_readl(i3c->regs, NDBSTLV0)) && !cmd->err)
bytes_remaining = data_len - cmd->rx_count;
i3c_readl_fifo(i3c->regs + NTDTBP0, cmd->rx_buf, bytes_remaining);
If rx_count remains 0, actual_len will always be 0. Will the new
i3c_ccc_validate_payload_len() logic then unconditionally reject the
payload with -EIO due to a short read?
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782824628.git.tze.yee.ng@altera.com?part=3
next prev parent reply other threads:[~2026-06-30 13:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-30 13:20 [PATCH v4 0/3] i3c: Improve CCC reliability for DesignWare master tze.yee.ng
2026-06-30 13:20 ` [PATCH v4 1/3] i3c: master: dw: Report actual GET CCC payload length on success tze.yee.ng
2026-06-30 13:31 ` sashiko-bot
2026-06-30 17:03 ` Frank Li
2026-07-01 2:46 ` NG, TZE YEE
2026-07-01 10:37 ` Alexandre Mergnat
2026-06-30 13:20 ` [PATCH v4 2/3] i3c: master: dw: Map CCC hardware errors to I3C M0/M2 tze.yee.ng
2026-06-30 13:32 ` sashiko-bot
2026-06-30 17:06 ` Frank Li
2026-07-01 2:45 ` NG, TZE YEE
2026-07-01 10:37 ` Alexandre Mergnat
2026-06-30 13:20 ` [PATCH v4 3/3] i3c: master: Validate GET CCC payload length and retry Direct GET once tze.yee.ng
2026-06-30 13:41 ` sashiko-bot [this message]
2026-06-30 18:48 ` Frank Li
2026-07-01 10:37 ` Alexandre Mergnat
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=20260630134148.C281F1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=imx@lists.linux.dev \
--cc=linux-i3c@lists.infradead.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tze.yee.ng@altera.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox