Re: [PATCH v4 20/52] clk: qcom: gcc-sa8775p: Tie the CX power domain to controller

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Asserting a reset via the generic reset framework can cause a synchronous external abort when the GCC controller is runtime suspended.
--

commit 7874573f5500623d6e83e44dfea983e35bc931dd
Author: Abel Vesa <abel.vesa@oss.qualcomm.com>

clk: qcom: gcc-sa8775p: Tie the CX power domain to controller

This commit enables runtime PM for the GCC controller by setting use_rpm to
true. This allows the CX power domain to be powered down once all GCC
consumers have released their clocks and GDSCs.

> diff --git a/drivers/clk/qcom/gcc-sa8775p.c b/drivers/clk/qcom/gcc-sa8775p.c
> index dca316decd0e6..2f867596bbc5c 100644
> --- a/drivers/clk/qcom/gcc-sa8775p.c
> +++ b/drivers/clk/qcom/gcc-sa8775p.c
> @@ -4652,6 +4652,7 @@ static const struct qcom_cc_desc gcc_sa8775p_desc = {
>  	.num_resets = ARRAY_SIZE(gcc_sa8775p_resets),
>  	.gdscs = gcc_sa8775p_gdscs,
>  	.num_gdscs = ARRAY_SIZE(gcc_sa8775p_gdscs),
> +	.use_rpm = true,

[Severity: High]
Could enabling use_rpm here cause a synchronous external abort during device
resets?

The QCOM reset controller operations, such as qcom_reset_set_assert(), perform
raw regmap MMIO writes but neither the reset core nor the qcom reset ops take
a PM runtime reference beforehand. Additionally, gcc_sa8775p_regmap_config has
no PM runtime awareness.

If a consumer driver (such as PCIe or UFS) calls reset_control_assert() before
enabling any GCC clocks, the register write will hit a powered-off bus because
the CX power domain is suspended.

Should the reset controller paths take a PM runtime reference to ensure the
hardware is accessible before allowing the bus to be powered down?

>  };
>  
>  static const struct of_device_id gcc_sa8775p_match_table[] = {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260914-qcom-tie-cx-to-gcc-v4-0-9d5a606ada33@oss.qualcomm.com?part=20