From: sashiko-bot@kernel.org
To: "Shubham Patil" <shubhamsanjay.patil@amd.com>
Cc: linux-i3c@lists.infradead.org, devicetree@vger.kernel.org,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
conor+dt@kernel.org, robh@kernel.org, Frank.Li@kernel.org
Subject: Re: [PATCH v2 2/2] i3c: master: dw: Drop redundant core reset name
Date: Mon, 20 Jul 2026 07:45:30 +0000 [thread overview]
Message-ID: <20260720074530.DCC3B1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260720073510.1869623-3-shubhamsanjay.patil@amd.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Medium] Missing device wakeup in the remove path causes unbalanced devres cleanup (double clock disable and double reset assert) if the device is in runtime suspend.
--
--- Patch [2]: [PATCH v2 2/2] i3c: master: dw: Drop redundant core reset name ---
commit 6e023481fe0a3988544e2173709b9f994efee394
Author: Shubham Patil <shubhamsanjay.patil@amd.com>
i3c: master: dw: Drop redundant core reset name
The DesignWare I3C master has a single reset line, so a dedicated
reset name is redundant. Look up the reset by index by passing NULL
instead of the "core_rst" name.
> diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i3c-master.c
> index 2f8c0c4683e06..488fb455d3cc8 100644
> --- a/drivers/i3c/master/dw-i3c-master.c
> +++ b/drivers/i3c/master/dw-i3c-master.c
> @@ -1584,7 +1584,7 @@ int dw_i3c_common_probe(struct dw_i3c_master *master,
> return PTR_ERR(master->pclk);
>
> master->core_rst = devm_reset_control_get_optional_exclusive_deasserted(&pdev->dev,
> - "core_rst");
> + NULL);
[Severity: Medium]
This is a pre-existing issue, but touching this devm allocation raises a
question about how devres cleans up during driver unbind.
Since devm_reset_control_get_optional_exclusive_deasserted() and the earlier
devm_clk_get_enabled() register devres actions to assert resets and disable
clocks, does dw_i3c_common_remove() need to wake the device before teardown?
If the device is runtime suspended during driver unbind,
dw_i3c_master_runtime_suspend() has already disabled clocks and asserted the
reset. Because dw_i3c_common_remove() does not call pm_runtime_get_sync() to
resume the device:
void dw_i3c_common_remove(struct dw_i3c_master *master)
{
i3c_master_unregister(&master->base);
/* Balance pm_runtime_get_noresume() from probe() */
if (master->quirks & DW_I3C_DISABLE_RUNTIME_PM_QUIRK)
pm_runtime_put_noidle(master->dev);
pm_runtime_disable(master->dev);
pm_runtime_set_suspended(master->dev);
pm_runtime_dont_use_autosuspend(master->dev);
}
The automatic devres cleanup will attempt to disable already-disabled clocks
and assert an already-asserted reset, which could trigger a noisy WARN from
the Common Clock Framework.
Could this double-cleanup be avoided by resuming the device before disabling
runtime PM in dw_i3c_common_remove()?
> if (IS_ERR(master->core_rst))
> return PTR_ERR(master->core_rst);
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720073510.1869623-1-shubhamsanjay.patil@amd.com?part=2
--
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
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, devicetree@vger.kernel.org,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
conor+dt@kernel.org, robh@kernel.org, Frank.Li@kernel.org
Subject: Re: [PATCH v2 2/2] i3c: master: dw: Drop redundant core reset name
Date: Mon, 20 Jul 2026 07:45:30 +0000 [thread overview]
Message-ID: <20260720074530.DCC3B1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260720073510.1869623-3-shubhamsanjay.patil@amd.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Medium] Missing device wakeup in the remove path causes unbalanced devres cleanup (double clock disable and double reset assert) if the device is in runtime suspend.
--
--- Patch [2]: [PATCH v2 2/2] i3c: master: dw: Drop redundant core reset name ---
commit 6e023481fe0a3988544e2173709b9f994efee394
Author: Shubham Patil <shubhamsanjay.patil@amd.com>
i3c: master: dw: Drop redundant core reset name
The DesignWare I3C master has a single reset line, so a dedicated
reset name is redundant. Look up the reset by index by passing NULL
instead of the "core_rst" name.
> diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i3c-master.c
> index 2f8c0c4683e06..488fb455d3cc8 100644
> --- a/drivers/i3c/master/dw-i3c-master.c
> +++ b/drivers/i3c/master/dw-i3c-master.c
> @@ -1584,7 +1584,7 @@ int dw_i3c_common_probe(struct dw_i3c_master *master,
> return PTR_ERR(master->pclk);
>
> master->core_rst = devm_reset_control_get_optional_exclusive_deasserted(&pdev->dev,
> - "core_rst");
> + NULL);
[Severity: Medium]
This is a pre-existing issue, but touching this devm allocation raises a
question about how devres cleans up during driver unbind.
Since devm_reset_control_get_optional_exclusive_deasserted() and the earlier
devm_clk_get_enabled() register devres actions to assert resets and disable
clocks, does dw_i3c_common_remove() need to wake the device before teardown?
If the device is runtime suspended during driver unbind,
dw_i3c_master_runtime_suspend() has already disabled clocks and asserted the
reset. Because dw_i3c_common_remove() does not call pm_runtime_get_sync() to
resume the device:
void dw_i3c_common_remove(struct dw_i3c_master *master)
{
i3c_master_unregister(&master->base);
/* Balance pm_runtime_get_noresume() from probe() */
if (master->quirks & DW_I3C_DISABLE_RUNTIME_PM_QUIRK)
pm_runtime_put_noidle(master->dev);
pm_runtime_disable(master->dev);
pm_runtime_set_suspended(master->dev);
pm_runtime_dont_use_autosuspend(master->dev);
}
The automatic devres cleanup will attempt to disable already-disabled clocks
and assert an already-asserted reset, which could trigger a noisy WARN from
the Common Clock Framework.
Could this double-cleanup be avoided by resuming the device before disabling
runtime PM in dw_i3c_common_remove()?
> if (IS_ERR(master->core_rst))
> return PTR_ERR(master->core_rst);
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720073510.1869623-1-shubhamsanjay.patil@amd.com?part=2
next prev parent reply other threads:[~2026-07-20 7:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 7:35 [PATCH v2 0/2] i3c: dw: Document optional core reset and drop redundant name Shubham Patil
2026-07-20 7:35 ` Shubham Patil
2026-07-20 7:35 ` [PATCH v2 1/2] dt-bindings: i3c: dw: Document missing optional core reset Shubham Patil
2026-07-20 7:35 ` Shubham Patil
2026-07-20 7:42 ` Pandey, Radhey Shyam
2026-07-20 7:42 ` Pandey, Radhey Shyam
2026-07-20 7:43 ` sashiko-bot
2026-07-20 7:43 ` sashiko-bot
2026-07-20 15:42 ` Frank Li
2026-07-20 15:42 ` Frank Li
2026-07-20 7:35 ` [PATCH v2 2/2] i3c: master: dw: Drop redundant core reset name Shubham Patil
2026-07-20 7:35 ` Shubham Patil
2026-07-20 7:41 ` Pandey, Radhey Shyam
2026-07-20 7:41 ` Pandey, Radhey Shyam
2026-07-20 7:45 ` sashiko-bot [this message]
2026-07-20 7:45 ` sashiko-bot
2026-07-20 15:43 ` Frank Li
2026-07-20 15:43 ` 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=20260720074530.DCC3B1F000E9@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.