Re: [PATCH v4 23/52] clk: qcom: gcc-sc7280: 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] Unclocked reset register access due to missing pm_runtime_get in qcom_reset_set_assert when use_rpm is enabled.
--

commit 8a72c09fdcc91da6e4bac8d90cd2e02793ef02c2
Author: Abel Vesa <abel.vesa@oss.qualcomm.com>

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

This commit enables runtime PM for the GCC controller, allowing the CX power
domain to be powered down once all consumers have released their clocks and
GDSCs.

> diff --git a/drivers/clk/qcom/gcc-sc7280.c b/drivers/clk/qcom/gcc-sc7280.c
> index 4502926a2691a..bb8f6efb88b1c 100644
> --- a/drivers/clk/qcom/gcc-sc7280.c
> +++ b/drivers/clk/qcom/gcc-sc7280.c
> @@ -3446,6 +3446,7 @@ static const struct qcom_cc_desc gcc_sc7280_desc = {
>  	.num_resets = ARRAY_SIZE(gcc_sc7280_resets),
>  	.gdscs = gcc_sc7280_gdscs,
>  	.num_gdscs = ARRAY_SIZE(gcc_sc7280_gdscs),
> +	.use_rpm = true,

[Severity: High]
Does enabling runtime PM here cause unclocked register accesses during reset
operations?

When use_rpm is true, the GCC controller can be runtime suspended. However,
the reset operations do not appear to resume the device before accessing
hardware registers:

drivers/clk/qcom/reset.c:qcom_reset_set_assert() {
    ...
    regmap_update_bits(rst->regmap, map->reg, mask, assert ? mask : 0);
    ...
}

If a consumer driver calls reset_control_assert() while the GCC is suspended
(for example, during a resume path before clocks are enabled, or during
probe if fw_devlink is disabled), could this unpowered register access
trigger a synchronous external abort and crash the system?

Should qcom_reset_set_assert() and similar reset callbacks call
pm_runtime_resume_and_get() before touching the hardware to ensure the
CX domain is actively powered on?

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

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