From: sashiko-bot@kernel.org
To: "Jiaxing Hu" <gahing@gahingwoo.com>
Cc: robh@kernel.org, conor+dt@kernel.org,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org
Subject: Re: [RFC PATCH 3/9] pmdomain/rockchip: cycle optional power-domain resets on power-on
Date: Fri, 17 Jul 2026 09:04:44 +0000 [thread overview]
Message-ID: <20260717090445.03F621F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260717085220.3212274-4-gahing@gahingwoo.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Missing `reset_control_put()` in `rockchip_pm_remove_one_domain()` leaks reset controls on probe failure.
--
--- Patch [3]: [RFC PATCH 3/9] pmdomain/rockchip: cycle optional power-domain resets on power-on ---
commit dbabfedb9da6564f3dfbd42512d2a456cfb08c18
Author: Jiaxing Hu <gahing@gahingwoo.com>
pmdomain/rockchip: cycle optional power-domain resets on power-on
This commit adds optional reset line handling to the Rockchip power domain
driver. It explicitly asserts and deasserts the reset lines during domain
power-on to ensure hardware bus interfaces are correctly initialized.
> diff --git a/drivers/pmdomain/rockchip/pm-domains.c b/drivers/pmdomain/rockchip/pm-domains.c
> --- a/drivers/pmdomain/rockchip/pm-domains.c
> +++ b/drivers/pmdomain/rockchip/pm-domains.c
[ ... ]
> @@ -840,6 +848,14 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu *pmu,
> if (error)
> goto err_put_clocks;
>
> + pd->resets = of_reset_control_array_get_optional_exclusive(node);
> + if (IS_ERR(pd->resets)) {
> + error = PTR_ERR(pd->resets);
> + dev_err(pmu->dev, "%pOFn: failed to get resets: %d\n", node, error);
> + pd->resets = NULL;
> + goto err_unprepare_clocks;
> + }
> +
[Severity: Medium]
Since pd->resets is acquired here using a non-managed function, does it need
to be released in rockchip_pm_remove_one_domain()?
If a subsequent domain fails to probe, the error path tears down all
successfully added domains via rockchip_pm_remove_one_domain(). It looks like
that function destroys the domain and releases its clocks, but might miss
cleaning up these reset controls:
static void rockchip_pm_remove_one_domain(struct rockchip_pm_domain *pd)
{
...
clk_bulk_unprepare(pd->num_clks, pd->clks);
clk_bulk_put(pd->num_clks, pd->clks);
/* pd->resets does not appear to be freed here */
...
}
Would calling reset_control_put(pd->resets) in the removal path prevent a
resource leak here?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717085220.3212274-1-gahing@gahingwoo.com?part=3
next prev parent reply other threads:[~2026-07-17 9:04 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-17 8:50 [RFC PATCH 0/9] accel/rocket: RK3576 NPU (RKNN) enablement Jiaxing Hu
2026-07-17 8:50 ` Jiaxing Hu
2026-07-17 8:50 ` [RFC PATCH 1/9] dt-bindings: npu: rockchip: add rockchip,rk3576-rknn-core Jiaxing Hu
2026-07-17 8:50 ` Jiaxing Hu
2026-07-17 8:59 ` sashiko-bot
2026-07-17 10:02 ` Chaoyi Chen
2026-07-17 10:02 ` Chaoyi Chen
2026-07-17 8:50 ` [RFC PATCH 2/9] pmdomain/rockchip: add optional per-domain power-on settle delay Jiaxing Hu
2026-07-17 8:50 ` Jiaxing Hu
2026-07-17 9:07 ` sashiko-bot
2026-07-17 8:50 ` [RFC PATCH 3/9] pmdomain/rockchip: cycle optional power-domain resets on power-on Jiaxing Hu
2026-07-17 8:50 ` Jiaxing Hu
2026-07-17 9:04 ` sashiko-bot [this message]
2026-07-17 8:50 ` [RFC PATCH 4/9] iommu/rockchip: skip orphaned-fault banks in rk_iommu_is_stall_active Jiaxing Hu
2026-07-17 8:50 ` Jiaxing Hu
2026-07-17 9:11 ` sashiko-bot
2026-07-17 10:15 ` Chaoyi Chen
2026-07-17 10:15 ` Chaoyi Chen
2026-07-17 8:50 ` [RFC PATCH 5/9] iommu/rockchip: skip orphaned-fault banks in CMD_ENABLE_STALL dispatch Jiaxing Hu
2026-07-17 8:50 ` Jiaxing Hu
2026-07-17 9:23 ` sashiko-bot
2026-07-17 8:50 ` [RFC PATCH 6/9] iommu/rockchip: take all DT clocks Jiaxing Hu
2026-07-17 8:50 ` Jiaxing Hu
2026-07-17 10:19 ` Chaoyi Chen
2026-07-17 10:19 ` Chaoyi Chen
2026-07-17 8:50 ` [RFC PATCH 7/9] accel/rocket: add RK3576 NPU (RKNN) support Jiaxing Hu
2026-07-17 8:50 ` Jiaxing Hu
2026-07-17 9:21 ` sashiko-bot
2026-07-17 10:29 ` Chaoyi Chen
2026-07-17 10:29 ` Chaoyi Chen
2026-07-17 8:50 ` [RFC PATCH 8/9] arm64: dts: rockchip: rk3576: add NPU (RKNN) nodes Jiaxing Hu
2026-07-17 8:50 ` Jiaxing Hu
2026-07-17 9:30 ` sashiko-bot
2026-07-17 8:50 ` [RFC PATCH 9/9] arm64: dts: rockchip: rk3576-rock-4d: enable NPU Jiaxing Hu
2026-07-17 8:50 ` Jiaxing Hu
2026-07-17 9:32 ` 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=20260717090445.03F621F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gahing@gahingwoo.com \
--cc=robh@kernel.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 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.