Re: [RFC PATCH v5 v5 5/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:
- [Medium] Using dev_err() instead of dev_err_probe() for reset acquisition leads to spurious boot warnings.
--

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

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

This commit cycles the resets for Rockchip power domains when they are powered
on. This clears undefined bus interface states that can cause hangs on devices
like the RK3576 NPU on the first access after a cold power-on.

> 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

[ ... ]

> @@ -857,6 +866,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);

[Severity: Medium]
Could this cause spurious boot warnings if the reset controller hasn't probed
yet?

When of_reset_control_array_get_optional_exclusive() returns -EPROBE_DEFER,
dev_err() will log an unconditional error instead of handling the deferral
silently. Should this use dev_err_probe() to cleanly handle deferred probes
without adding spam to the kernel log?

> +		pd->resets = NULL;
> +		goto err_unprepare_clocks;
> +	}
> +
>  	pd->num_qos = of_count_phandle_with_args(node, "pm_qos",
>  						 NULL);

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