Re: [PATCH] clk: qcom: clk-pll: reject vote enable on orphan parent

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 6/2/26 8:29 AM, Herman van Hazendonk wrote:
> clk_pll_vote_enable() unconditionally feeds the result of
> clk_hw_get_parent(hw) through to_clk_pll() and on to wait_for_pll().
> The common clock framework permits clk_enable() on an orphan clock
> (supplier not bound yet), in which case clk_hw_get_parent() returns
> NULL. to_clk_pll(NULL) then yields container_of(NULL, struct clk_pll,
> clkr) -- a non-NULL bogus pointer pointing into the negative offset
> of struct clk_pll.
> 
> wait_for_pll() reaches for the parent's name via
> clk_hw_get_name(&pll->clkr.hw). Because clkr sits at a fixed offset
> inside struct clk_pll, &pll->clkr.hw cancels the to_clk_pll offset
> exactly back to NULL and clk_hw_get_name() then dereferences
> core->name on a NULL clk_hw, panicking the kernel.
> 
> This is reachable today: gcc-msm8960.c and gcc-apq8064.c register a
> pll4_vote whose parent (pll4) lives in lcc-msm8960.c, and the future
> gcc-msm8660 pll4_vote does the same. If anything calls clk_enable()
> on pll4_vote between gcc probe and the LCC clock controller binding,
> the system panics. The exposure widens as more SoCs adopt the same
> cross-controller voter pattern.

Hm, I think this is a side-effect of the olden global clock by-name
lookup (i.e. parent_data.name). Nowadays this shouldn't be much of
an issue because of fw_devlink ensuring correct ordering.

There is already a reference in the dts, since about 2022:

80787e417f30 ("ARM: dts: qcom: msm8960: add clocks to the GCC device node")

Are there any other cross-dependencies between GCC and LCC?

Anyway, for this patch:

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad