From: sashiko-bot@kernel.org
To: "Claudiu Beznea" <claudiu.beznea@kernel.org>
Cc: Frank.Li@kernel.org, wsa+renesas@sang-engineering.com,
linux-i3c@lists.infradead.org
Subject: Re: [PATCH v3 04/17] i3c: renesas: Reconfigure the DATBAS register on re-attach
Date: Mon, 08 Jun 2026 20:28:14 +0000 [thread overview]
Message-ID: <20260608202814.CB9C51F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260608201543.804902-5-claudiu.beznea@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The reattach_i3c_dev function unconditionally moves devices to a different free index on every call, causing endless index bouncing, array fragmentation, and unnecessary DATBAS register rewrites, which likely breaks Dynamic Address Assignment (DAA).
--
commit 15d5e07352154039ed134b971df0d63e73d607c0
Author: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
i3c: renesas: Reconfigure the DATBAS register on re-attach
This commit reconfigures the DATBAS register during device re-attach when a
device changes its position in the i3c->addrs[] array. It also updates the
software caches.
> diff --git a/drivers/i3c/master/renesas-i3c.c b/drivers/i3c/master/renesas-i3c.c
> index 4c86e72578043..76a4831098c94 100644
> --- a/drivers/i3c/master/renesas-i3c.c
> +++ b/drivers/i3c/master/renesas-i3c.c
> @@ -892,10 +892,26 @@ static int renesas_i3c_reattach_i3c_dev(struct i3c_dev_desc *dev,
> struct i3c_master_controller *m = i3c_dev_get_master(dev);
> struct renesas_i3c *i3c = to_renesas_i3c(m);
> struct renesas_i3c_i2c_dev_data *data = i3c_dev_get_master_data(dev);
> + int pos;
> +
> + pos = renesas_i3c_get_free_pos(i3c);
> +
> + if (data->index != pos && pos >= 0) {
[Severity: High]
Does this logic unconditionally move devices to a different index on every
reattach call?
Because the device currently occupies data->index, that index's bit is cleared
in i3c->free_pos (meaning it is not free). Therefore, the lowest free slot
(pos) returned by renesas_i3c_get_free_pos() can never equal the currently
occupied slot (data->index).
As a result, this condition unconditionally evaluates to true on every
reattach call as long as a free slot exists. This forces the device to vacate
its current hardware index, move to the new position, and rewrite its DATBAS
registers, resulting in perpetual ping-ponging of slots instead of compacting
the array.
Furthermore, this fragmentation leaves lower indices free while upper ones are
occupied. During renesas_i3c_daa(), the controller calculates the number of
expected DAA devices as maxdevs - ret (where ret is the lowest free index).
If there are fragmented active devices at higher indices, will the hardware's
sequential DAA assignment overwrite their DATBAS configuration and lead to
functional failures?
> + renesas_writel(i3c->regs, DATBAS(data->index), 0);
> + i3c->addrs[data->index] = 0;
> + i3c->free_pos |= BIT(data->index);
> +
> + data->index = pos;
> + i3c->free_pos &= ~BIT(data->index);
> + }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260608201543.804902-1-claudiu.beznea@kernel.org?part=4
--
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:28 UTC|newest]
Thread overview: 48+ 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 ` 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:15 ` 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:15 ` 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 ` 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:15 ` Claudiu Beznea
2026-06-08 20:28 ` sashiko-bot [this message]
2026-06-08 20:15 ` [PATCH v3 05/17] i3c: renesas: Reset the controller on resume Claudiu Beznea
2026-06-08 20:15 ` 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:15 ` 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:15 ` 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:15 ` 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 ` 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:15 ` Claudiu Beznea
2026-06-08 20:27 ` sashiko-bot
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:15 ` 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 ` 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:15 ` 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 ` 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:15 ` 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 ` Claudiu Beznea
2026-06-08 20:15 ` [PATCH v3 17/17] i3c: renesas: Add runtime PM support Claudiu Beznea
2026-06-08 20:15 ` 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=20260608202814.CB9C51F00893@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 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.