From: sashiko-bot@kernel.org
To: "Claudiu Beznea" <claudiu.beznea@kernel.org>
Cc: Frank.Li@kernel.org, linux-i3c@lists.infradead.org,
wsa+renesas@sang-engineering.com
Subject: Re: [PATCH v3 10/17] i3c: renesas: Return immediately if there is no transfer
Date: Mon, 08 Jun 2026 20:27:48 +0000 [thread overview]
Message-ID: <20260608202748.EA1141F00898@smtp.kernel.org> (raw)
In-Reply-To: <20260608201543.804902-11-claudiu.beznea@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but the return value of `wait_for_completion_timeout()` is ignored in `renesas_i3c_i2c_xfers()`, leading to falsely reporting success on timeouts and continuing to issue subsequent messages to a hung bus.
- [High] This problem wasn't introduced by this patch, but transfer completion status (`xfer->ret`) is completely ignored in `renesas_i3c_i3c_xfers()`, causing all I3C private transfers to unconditionally report success even if they fail or time out.
--
commit c9a5059d97052e39bcba94fdb82d462a309a98d2
Author: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
i3c: renesas: Return immediately if there is no transfer
There is no need to allocate a transfer structure when i2c_nxfers is zero.
Return immediately instead of unnecessarily allocating memory.
> diff --git a/drivers/i3c/master/renesas-i3c.c b/drivers/i3c/master/renesas-i3c.c
> index 4a055c9f4ffea..1fd39dd578474 100644
> --- a/drivers/i3c/master/renesas-i3c.c
> +++ b/drivers/i3c/master/renesas-i3c.c
> @@ -1066,13 +1066,13 @@ static int renesas_i3c_i2c_xfers(struct i2c_dev_desc *dev,
> u8 start_bit = CNDCTL_STCND;
> int i;
>
> + if (!i2c_nxfers)
> + return 0;
> +
[Severity: High]
This isn't a bug introduced by this patch, but the return value of
wait_for_completion_timeout() is ignored later in renesas_i3c_i2c_xfers():
wait_for_completion_timeout(&xfer->comp, m->i2c.timeout);
if (cmd->err)
break;
When wait_for_completion_timeout() returns 0 (indicating a timeout), there
is no check to set cmd->err. Since cmd->err remains 0, the loop incorrectly
continues to issue start conditions for remaining messages on the timed-out
bus.
Finally, the function returns cmd->err (0), falsely reporting success to
the I2C subsystem. Does this silently hide I2C timeouts from caller drivers?
[Severity: High]
This isn't a bug introduced by this patch, but transfer completion status
is completely ignored in renesas_i3c_i3c_xfers() in the same file:
renesas_i3c_wait_xfer(i3c, xfer);
}
return 0;
The function renesas_i3c_wait_xfer() records completion status (e.g., -EIO,
-ENOSPC, -ETIMEDOUT) in xfer->ret. However, the loop never inspects
xfer->ret and unconditionally returns 0 at the end.
Could this silently hide NACKs, parity errors, and timeouts from I3C target
drivers, breaking the subsystem's error handling and leading to false
assumptions about data validity?
> struct renesas_i3c_xfer *xfer __free(kfree) = renesas_i3c_alloc_xfer(i3c, 1);
> if (!xfer)
> return -ENOMEM;
>
> - if (!i2c_nxfers)
> - return 0;
> -
> renesas_i3c_bus_enable(m, false);
>
> init_completion(&xfer->comp);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260608201543.804902-1-claudiu.beznea@kernel.org?part=10
--
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
next prev parent reply other threads:[~2026-06-08 20:27 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 20:15 [PATCH v3 00/17] i3c: renesas: Suspend to RAM with power loss and runtime PM Claudiu Beznea
2026-06-08 20:15 ` [PATCH v3 01/17] i3c: renesas: Check that the transfer is valid before accessing it Claudiu Beznea
2026-06-08 20:31 ` sashiko-bot
2026-06-08 20:15 ` [PATCH v3 02/17] i3c: renesas: Restore STDBR and EXTBR registers on resume Claudiu Beznea
2026-06-08 20:32 ` sashiko-bot
2026-06-08 20:15 ` [PATCH v3 03/17] i3c: renesas: Follow the reset deassert order used in probe Claudiu Beznea
2026-06-08 20:15 ` [PATCH v3 04/17] i3c: renesas: Reconfigure the DATBAS register on re-attach Claudiu Beznea
2026-06-08 20:28 ` sashiko-bot
2026-06-08 20:15 ` [PATCH v3 05/17] i3c: renesas: Reset the controller on resume Claudiu Beznea
2026-06-08 20:29 ` sashiko-bot
2026-06-08 20:15 ` [PATCH v3 06/17] i3c: renesas: Perform Dynamic Address Assignment " Claudiu Beznea
2026-06-08 20:36 ` sashiko-bot
2026-06-08 20:15 ` [PATCH v3 07/17] i3c: renesas: Do not attach devices if xfer failed Claudiu Beznea
2026-06-08 20:29 ` sashiko-bot
2026-06-08 20:15 ` [PATCH v3 08/17] i3c: renesas: Clean DATBAS register on detach Claudiu Beznea
2026-06-08 20:38 ` sashiko-bot
2026-06-08 20:15 ` [PATCH v3 09/17] i3c: renesas: Use reset_control_bulk_{assert, deassert}() Claudiu Beznea
2026-06-08 20:15 ` [PATCH v3 10/17] i3c: renesas: Return immediately if there is no transfer Claudiu Beznea
2026-06-08 20:27 ` sashiko-bot [this message]
2026-06-08 20:15 ` [PATCH v3 11/17] i3c: renesas: Follow a unified pattern for transfer and command initialization Claudiu Beznea
2026-06-08 20:30 ` sashiko-bot
2026-06-08 20:15 ` [PATCH v3 12/17] i3c: renesas: Drop the explicit memset() call Claudiu Beznea
2026-06-08 20:15 ` [PATCH v3 13/17] i3c: renesas: Update HW registers after SW computations are done Claudiu Beznea
2026-06-08 20:38 ` sashiko-bot
2026-06-08 20:15 ` [PATCH v3 14/17] i3c: renesas: Organize structures to avoid unnecessary padding Claudiu Beznea
2026-06-08 20:15 ` [PATCH v3 15/17] i3c: renesas: Use the "dev_name:irq_name" format for the interrupt name Claudiu Beznea
2026-06-08 20:41 ` sashiko-bot
2026-06-08 20:15 ` [PATCH v3 16/17] i3c: renesas: Drop unnecessary tab Claudiu Beznea
2026-06-08 20:15 ` [PATCH v3 17/17] i3c: renesas: Add runtime PM support Claudiu Beznea
2026-06-08 20:46 ` sashiko-bot
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=20260608202748.EA1141F00898@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=claudiu.beznea@kernel.org \
--cc=linux-i3c@lists.infradead.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=wsa+renesas@sang-engineering.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