Re: [RFC PATCH v2 3/8] pmdomain/rockchip: cycle optional power-domain resets on power-on

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Probe error path fails to remove parent power domains (due to subdomain links), leaving freed memory linked in the global genpd list, leading to a Use-After-Free.
--

--- Patch [3]: [RFC PATCH v2 3/8] pmdomain/rockchip: cycle optional power-domain resets on power-on ---
commit 6b47e7abcdceaeb541eb946e08c3911e47f8d51e
Author: Jiaxing Hu <gahing@gahingwoo.com>

pmdomain/rockchip: cycle optional power-domain resets on power-on

This commit adds support for an optional resets property to the rockchip
power domain driver. Resets are now explicitly asserted and deasserted
during the power-on sequence to ensure the hardware interfaces observe
the necessary reset edge.

> diff --git a/drivers/pmdomain/rockchip/pm-domains.c b/drivers/pmdomain/rockchip/pm-domains.c
> index 1787f62ba3a81..8ce0cc3de0bfb 100644
> --- a/drivers/pmdomain/rockchip/pm-domains.c
> +++ b/drivers/pmdomain/rockchip/pm-domains.c

[ ... ]

> @@ -928,6 +945,7 @@ 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);
> +	reset_control_put(pd->resets);

[Severity: Critical]
This is a pre-existing issue, but does this error path leave freed memory
linked in the global genpd list?

When a probe failure triggers cleanup via rockchip_pm_domain_cleanup(), it
iterates over all domains and calls rockchip_pm_remove_one_domain().

Since subdomain links are not explicitly removed first, pm_genpd_remove()
fails with -EBUSY for parent domains and leaves them linked in the global
gpd_list:

rockchip_pm_remove_one_domain()
    ret = pm_genpd_remove(&pd->genpd);
    if (ret < 0)
        dev_err(...) // -EBUSY is caught here but ignored

Because devm will subsequently free the rockchip_pm_domain structure which
embeds the genpd structure, could this lead to a use-after-free later when
the genpd core iterates gpd_list, for instance in genpd_power_off_unused()?

>  
>  	/* protect the zeroing of pm->num_clks */
>  	mutex_lock(&pd->pmu->mutex);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260718031146.3368811-1-gahing@gahingwoo.com?part=3