Re: [PATCH v3 01/12] clk: qcom: gcc-qcm2290: Keep the critical clocks always-on from probe

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Removing UAPI clock identifiers from the clock provider array shrinks the array size and removes mapped entries, breaking backward compatibility with existing device trees.
--

commit 70f7cf6dd1977dd3ca34d8d9a83d70fb0593afab
Author: Imran Shaik <imran.shaik@oss.qualcomm.com>

clk: qcom: gcc-qcm2290: Keep the critical clocks always-on from probe

Some GCC branch clocks are required to be kept always-on due to the
hardware requirements. Drop the modelling of those always-on QCM2290 GCC
clocks and use the latest .clk_cbcr convention to keep them enabled from
probe.

> diff --git a/drivers/clk/qcom/gcc-qcm2290.c b/drivers/clk/qcom/gcc-qcm2290.c
> index 6684cab63ae11..8d18bbbca0aaf 100644
> --- a/drivers/clk/qcom/gcc-qcm2290.c
> +++ b/drivers/clk/qcom/gcc-qcm2290.c

[ ... ]

> @@ -2887,13 +2747,11 @@ static struct clk_regmap *gcc_qcm2290_clocks[] = {
>  	[GCC_VCODEC0_AXI_CLK] = &gcc_vcodec0_axi_clk.clkr,
>  	[GCC_VENUS_AHB_CLK] = &gcc_venus_ahb_clk.clkr,
>  	[GCC_VENUS_CTL_AXI_CLK] = &gcc_venus_ctl_axi_clk.clkr,
> -	[GCC_VIDEO_AHB_CLK] = &gcc_video_ahb_clk.clkr,
>  	[GCC_VIDEO_AXI0_CLK] = &gcc_video_axi0_clk.clkr,
>  	[GCC_VIDEO_THROTTLE_CORE_CLK] = &gcc_video_throttle_core_clk.clkr,
>  	[GCC_VIDEO_VCODEC0_SYS_CLK] = &gcc_video_vcodec0_sys_clk.clkr,
>  	[GCC_VIDEO_VENUS_CLK_SRC] = &gcc_video_venus_clk_src.clkr,
>  	[GCC_VIDEO_VENUS_CTL_CLK] = &gcc_video_venus_ctl_clk.clkr,
> -	[GCC_VIDEO_XO_CLK] = &gcc_video_xo_clk.clkr,
>  	[GPLL0] = &gpll0.clkr,
>  	[GPLL0_OUT_AUX2] = &gpll0_out_aux2.clkr,
>  	[GPLL1] = &gpll1.clkr,

[Severity: High]
Does removing these clocks from the array break backward compatibility with
existing device trees?

By removing GCC_VIDEO_XO_CLK (which is the highest index defined in the DT
bindings) and other clocks from gcc_qcm2290_clocks, the array size
implicitly shrinks.

When consumer drivers attempt to acquire these clocks via clk_get(), the
bounds check in qcom_cc_clk_hw_get() will now fail or return NULL, returning
-EINVAL instead of a valid clock.

Will existing device trees referencing these clocks cause their consumer
drivers to fail to probe?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260601-shikra-dispcc-gpucc-v3-0-61c1ba3735e8@oss.qualcomm.com?part=1