From: sashiko-bot@kernel.org
To: "Akhil R" <akhilrajeev@nvidia.com>
Cc: "Alexandre Belloni" <alexandre.belloni@bootlin.com>,
linux-i3c@lists.infradead.org, Frank.Li@kernel.org
Subject: Re: [PATCH 5/5] i3c: dw: Resume the controller before unregistering the bus
Date: Tue, 04 Aug 2026 11:15:31 +0000 [thread overview]
Message-ID: <20260804111532.4244F1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260804101301.2975911-6-akhilrajeev@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] If pm_runtime_resume_and_get() fails, the driver logs an error but proceeds to unregister the bus, which accesses hardware registers while clocks are gated, causing a system hang.
--
--- Patch [5]: [PATCH 5/5] i3c: dw: Resume the controller before unregistering the bus ---
commit 505f2f2b67429286e85c86a3aafae3b5a8a3a876
Author: Akhil R <akhilrajeev@nvidia.com>
i3c: dw: Resume the controller before unregistering the bus
Unregistering the I3C bus without resuming the device accesses registers
with gated clocks, causing system hangs. This commit resumes the device
around unregistration to ensure the clocks are running for register accesses.
Closes: https://lore.kernel.org/all/20260728071757.5B3CD1F000E9@smtp.kernel.org/
--- a/drivers/i3c/master/dw-i3c-master.c
+++ b/drivers/i3c/master/dw-i3c-master.c
@@ -1723,8 +1723,20 @@ EXPORT_SYMBOL_GPL(dw_i3c_common_probe);
void dw_i3c_common_remove(struct dw_i3c_master *master)
{
+ int ret;
+
+ /* Unregistering the bus accesses the controller registers */
+ ret = pm_runtime_resume_and_get(master->dev);
+ if (ret < 0)
+ dev_err(master->dev,
+ "<%s> cannot resume i3c bus master, err: %d\n",
+ __func__, ret);
+
i3c_master_unregister(&master->base);
[Severity: High]
This is a pre-existing issue, but if pm_runtime_resume_and_get() fails here,
will the driver still proceed to call i3c_master_unregister()?
If the resume fails (for example, due to a power domain or clock enablement
failure), the clocks remain gated. Calling i3c_master_unregister() will
unconditionally invoke the cleanup path:
dw_i3c_common_remove()
i3c_master_unregister()
i3c_master_bus_cleanup()
dw_i3c_master_disable()
Inside dw_i3c_master_disable(), the code will attempt to read the DEVICE_CTRL
register while the hardware is still unclocked.
Could this lead to the same system crash (such as a Data Abort) that this
patch is trying to prevent by accessing memory-mapped registers of the
power-gated hardware block?
> + if (ret >= 0)
> + pm_runtime_put_noidle(master->dev);
> +
> /* Balance pm_runtime_get_noresume() from probe() */
> if (master->quirks & DW_I3C_DISABLE_RUNTIME_PM_QUIRK)
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260804101301.2975911-1-akhilrajeev@nvidia.com?part=5
--
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
next prev parent reply other threads:[~2026-08-04 11:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 10:12 [PATCH 0/5] i3c: Fix firmware node refcounting and error paths Akhil R
2026-08-04 10:12 ` [PATCH 1/5] i3c: master: Release the fwnode of i2c boardinfo Akhil R
2026-08-04 10:33 ` sashiko-bot
2026-08-05 19:07 ` Frank Li
2026-08-04 16:53 ` Adrian Hunter
2026-08-04 10:12 ` [PATCH 2/5] i3c: master: Fix refcount of i3c fwnode Akhil R
2026-08-04 16:53 ` Adrian Hunter
2026-08-04 10:12 ` [PATCH 3/5] i3c: master: Do not release the addresses when reattach fails Akhil R
2026-08-04 17:56 ` Adrian Hunter
2026-08-04 10:13 ` [PATCH 4/5] i3c: dw: Do not use OF match data as a quirk bitmask Akhil R
2026-08-04 11:04 ` sashiko-bot
2026-08-05 19:53 ` Frank Li
2026-08-04 10:13 ` [PATCH 5/5] i3c: dw: Resume the controller before unregistering the bus Akhil R
2026-08-04 11:15 ` sashiko-bot [this message]
2026-08-05 19:57 ` Frank Li
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=20260804111532.4244F1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=akhilrajeev@nvidia.com \
--cc=alexandre.belloni@bootlin.com \
--cc=linux-i3c@lists.infradead.org \
--cc=sashiko-reviews@lists.linux.dev \
/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