Re: [PATCH v8 3/7] clk: qcom: Add generic clkref_en support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Uninitialized stack memory read in qcom_clk_ref_provider_get due to missing args_count check.
--

--- Patch [3]: [PATCH v8 3/7] clk: qcom: Add generic clkref_en support ---
commit 5fbeeca574eafbc5d86afc2e9ee00af52b02a04f
Author: Qiang Yu <qiang.yu@oss.qualcomm.com>

clk: qcom: Add generic clkref_en support

This commit adds generic support for clkref_en clocks in Qualcomm platforms.
It introduces a dedicated clk_ref clock type with custom operations that
manage both the enable bit and associated regulators, and provides a common
probe and registration API.

> diff --git a/drivers/clk/qcom/clk-ref.c b/drivers/clk/qcom/clk-ref.c
> new file mode 100644
> index 0000000000000..3efdf6749770d
> --- /dev/null
> +++ b/drivers/clk/qcom/clk-ref.c

[ ... ]

> +static struct clk_hw *qcom_clk_ref_provider_get(struct of_phandle_args *clkspec, void *data)
> +{
> +	struct qcom_clk_ref_provider *provider = data;
> +	unsigned int idx = clkspec->args[0];

[Severity: Medium]
Could this read uninitialized stack memory if a device tree node is
malformed?

If a consumer requests a clock but the provider's device tree node
incorrectly specifies #clock-cells = <0>, the device tree parsing logic
will set args_count to 0 and leave the args array uninitialized. 

Would it be safer to verify clkspec->args_count >= 1 before reading
clkspec->args[0]?

> +
> +	if (idx >= provider->num_refs)
> +		return ERR_PTR(-EINVAL);
> +
> +	if (!provider->refs[idx].regmap)
> +		return ERR_PTR(-ENOENT);
> +
> +	return &provider->refs[idx].hw;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260708-tcsr_qref_0708-v8-0-62c42b5fa269@oss.qualcomm.com?part=3