From: sashiko-bot@kernel.org
To: "Shubham Patil" <shubhamsanjay.patil@amd.com>
Cc: linux-i3c@lists.infradead.org, Frank.Li@kernel.org,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
conor+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v4 3/3] i3c: master: amd: Add hot-join support
Date: Wed, 09 Sep 2026 07:29:54 +0000 [thread overview]
Message-ID: <20260909072955.3D8AA1F00A3E@smtp.kernel.org> (raw)
In-Reply-To: <20260909071340.3649271-4-shubhamsanjay.patil@amd.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The driver fails to clear `XI3C_CR_HJ_MASK` and `XI3C_CR_IBI_MASK` from the Core Control Register (`XI3C_CR_OFFSET`) during controller initialization. When the controller is subsequently enabled, any previously set bits (e.g., from a warm boot, kexec, or bootloader) remain active. This causes the controller to silently ACK hot-join or IBI requests on the bus without generating interrupts (since `XI3C_INTR_RE_OFFSET` is zeroed), irrevocably stalling bus enumeration.
--
commit 2fc8cea47a914e1d8d7312826561a084f785d035
Author: Shubham Patil <shubhamsanjay.patil@amd.com>
Subject: i3c: master: amd: Add hot-join support
This commit adds hot-join support for the AMD AXI I3C master controller.
It introduces sysfs-based configuration and handles events via the i3c core
hot-join queue to run DAA for enumerating new devices.
> diff --git a/drivers/i3c/master/amd-i3c-master.c b/drivers/i3c/master/amd-i3c-master.c
> index a50445530a430..400bf15e02992 100644
> --- a/drivers/i3c/master/amd-i3c-master.c
> +++ b/drivers/i3c/master/amd-i3c-master.c
[ ... ]
> @@ -1244,13 +1250,14 @@ static void xi3c_master_bus_cleanup(struct i3c_master_controller *m)
> struct xi3c_master *master = to_xi3c_master(m);
>
> /*
> - * Disarm all interrupt sources and the IBI ACK so the controller can't
> - * assert once disabled; reset the refcount that tracks them.
> + * Disarm the interrupts and the IBI/Hot-Join ACKs so nothing is left
> + * armed for a later bus_init(); reset the refcount that tracks them.
> */
> scoped_guard(spinlock_irqsave, &master->reg_lock) {
> iowrite32(0, master->membase + XI3C_INTR_RE_OFFSET);
> iowrite32(ioread32(master->membase + XI3C_CR_OFFSET) &
> - ~XI3C_CR_IBI_MASK, master->membase + XI3C_CR_OFFSET);
> + ~(XI3C_CR_IBI_MASK | XI3C_CR_HJ_MASK),
> + master->membase + XI3C_CR_OFFSET);
> master->ibi.enabled_count = 0;
> }
[Severity: High]
Does xi3c_master_init() also need to clear these masks from XI3C_CR_OFFSET to
guarantee a clean state before enabling the controller?
If the controller is enabled after a warm boot or kexec where a bootloader
left the Hot-Join bit active, the driver currently fails to clear it in
xi3c_master_init():
drivers/i3c/master/amd-i3c-master.c:xi3c_master_init() {
/* Mask all interrupt sources and clear any stale latched events. */
iowrite32(0, master->membase + XI3C_INTR_RE_OFFSET);
iowrite32(ioread32(master->membase + XI3C_INTR_STATUS_OFFSET),
master->membase + XI3C_INTR_STATUS_OFFSET);
/* Reset fifos */
xi3c_master_reset_fifos(master);
/* Enable controller */
xi3c_master_enable(master);
}
Since XI3C_INTR_RE_OFFSET is zeroed but the Hot-Join ACK bit might remain
active in XI3C_CR_OFFSET, could the controller silently ACK hot-join requests
without generating CPU interrupts, permanently stalling bus enumeration?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260909071340.3649271-1-shubhamsanjay.patil@amd.com?part=3
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Shubham Patil" <shubhamsanjay.patil@amd.com>
Cc: linux-i3c@lists.infradead.org, Frank.Li@kernel.org,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
conor+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v4 3/3] i3c: master: amd: Add hot-join support
Date: Wed, 09 Sep 2026 07:29:54 +0000 [thread overview]
Message-ID: <20260909072955.3D8AA1F00A3E@smtp.kernel.org> (raw)
In-Reply-To: <20260909071340.3649271-4-shubhamsanjay.patil@amd.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The driver fails to clear `XI3C_CR_HJ_MASK` and `XI3C_CR_IBI_MASK` from the Core Control Register (`XI3C_CR_OFFSET`) during controller initialization. When the controller is subsequently enabled, any previously set bits (e.g., from a warm boot, kexec, or bootloader) remain active. This causes the controller to silently ACK hot-join or IBI requests on the bus without generating interrupts (since `XI3C_INTR_RE_OFFSET` is zeroed), irrevocably stalling bus enumeration.
--
commit 2fc8cea47a914e1d8d7312826561a084f785d035
Author: Shubham Patil <shubhamsanjay.patil@amd.com>
Subject: i3c: master: amd: Add hot-join support
This commit adds hot-join support for the AMD AXI I3C master controller.
It introduces sysfs-based configuration and handles events via the i3c core
hot-join queue to run DAA for enumerating new devices.
> diff --git a/drivers/i3c/master/amd-i3c-master.c b/drivers/i3c/master/amd-i3c-master.c
> index a50445530a430..400bf15e02992 100644
> --- a/drivers/i3c/master/amd-i3c-master.c
> +++ b/drivers/i3c/master/amd-i3c-master.c
[ ... ]
> @@ -1244,13 +1250,14 @@ static void xi3c_master_bus_cleanup(struct i3c_master_controller *m)
> struct xi3c_master *master = to_xi3c_master(m);
>
> /*
> - * Disarm all interrupt sources and the IBI ACK so the controller can't
> - * assert once disabled; reset the refcount that tracks them.
> + * Disarm the interrupts and the IBI/Hot-Join ACKs so nothing is left
> + * armed for a later bus_init(); reset the refcount that tracks them.
> */
> scoped_guard(spinlock_irqsave, &master->reg_lock) {
> iowrite32(0, master->membase + XI3C_INTR_RE_OFFSET);
> iowrite32(ioread32(master->membase + XI3C_CR_OFFSET) &
> - ~XI3C_CR_IBI_MASK, master->membase + XI3C_CR_OFFSET);
> + ~(XI3C_CR_IBI_MASK | XI3C_CR_HJ_MASK),
> + master->membase + XI3C_CR_OFFSET);
> master->ibi.enabled_count = 0;
> }
[Severity: High]
Does xi3c_master_init() also need to clear these masks from XI3C_CR_OFFSET to
guarantee a clean state before enabling the controller?
If the controller is enabled after a warm boot or kexec where a bootloader
left the Hot-Join bit active, the driver currently fails to clear it in
xi3c_master_init():
drivers/i3c/master/amd-i3c-master.c:xi3c_master_init() {
/* Mask all interrupt sources and clear any stale latched events. */
iowrite32(0, master->membase + XI3C_INTR_RE_OFFSET);
iowrite32(ioread32(master->membase + XI3C_INTR_STATUS_OFFSET),
master->membase + XI3C_INTR_STATUS_OFFSET);
/* Reset fifos */
xi3c_master_reset_fifos(master);
/* Enable controller */
xi3c_master_enable(master);
}
Since XI3C_INTR_RE_OFFSET is zeroed but the Hot-Join ACK bit might remain
active in XI3C_CR_OFFSET, could the controller silently ACK hot-join requests
without generating CPU interrupts, permanently stalling bus enumeration?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260909071340.3649271-1-shubhamsanjay.patil@amd.com?part=3
--
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
next prev parent reply other threads:[~2026-09-09 7:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-09 7:13 [PATCH v4 0/3] i3c: master: amd: Add IBI and hot-join support Shubham Patil
2026-09-09 7:13 ` Shubham Patil
2026-09-09 7:13 ` [PATCH v4 1/3] dt-bindings: i3c: xlnx: Add IBI and hot-join capability properties Shubham Patil
2026-09-09 7:13 ` Shubham Patil
2026-09-09 15:34 ` Frank Li
2026-09-09 15:34 ` Frank Li
2026-09-09 7:13 ` [PATCH v4 2/3] i3c: master: amd: Add support for in-band interrupts Shubham Patil
2026-09-09 7:13 ` Shubham Patil
2026-09-09 7:30 ` sashiko-bot
2026-09-09 7:30 ` sashiko-bot
2026-09-09 7:13 ` [PATCH v4 3/3] i3c: master: amd: Add hot-join support Shubham Patil
2026-09-09 7:13 ` Shubham Patil
2026-09-09 7:29 ` sashiko-bot [this message]
2026-09-09 7:29 ` 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=20260909072955.3D8AA1F00A3E@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=alexandre.belloni@bootlin.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-i3c@lists.infradead.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=shubhamsanjay.patil@amd.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.