Linux kernel and device drivers for NXP i.MX platforms
 help / color / mirror / Atom feed
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

  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