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 <[email protected]> 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/[email protected]?part=3
