Re: [PATCH 2/3] soc: qcom: spm: Add MSM8960 SAW2 CPU support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Probe will panic or Oops due to a division by zero in spm_register_regulator() when computing drv->volt_sel.
--

commit 4745d4815a10beefae8a9bba0dd4e906c2f9bd24
Author: Rudraksha Gupta <guptarud@gmail.com>

soc: qcom: spm: Add MSM8960 SAW2 CPU support

The MSM8960 uses SAW2 v1.1, the same hardware version as the APQ8064. This
adds SPM register data to program the correct SPM sequences and PMIC
parameters for MSM8960 CPUs.

Link: https://github.com/CyanogenMod/android_kernel_samsung_d2/blob/0dbe2b56847b304d30b809dfd08ba3b4a61d9af8/arch/arm/mach-msm/board-express.c#L3353-L3381

> diff --git a/drivers/soc/qcom/spm.c b/drivers/soc/qcom/spm.c
> index f75659fff2874..596431b00a03e 100644
> --- a/drivers/soc/qcom/spm.c
> +++ b/drivers/soc/qcom/spm.c

[ ... ]

> @@ -501,6 +517,8 @@ static const struct of_device_id spm_match_table[] = {
>  	  .data = &spm_reg_8974_8084_cpu },
>  	{ .compatible = "qcom,apq8064-saw2-v1.1-cpu",
>  	  .data = &spm_reg_8064_cpu },
> +	{ .compatible = "qcom,msm8960-saw2-v1.1-cpu",
> +	  .data = &spm_reg_8960_cpu },

Will adding this compatible trigger a division by zero during device probe?

While this issue wasn't introduced by this patch, probing this device reveals
a division by zero in spm_register_regulator() when computing drv->volt_sel:

drivers/soc/qcom/spm.c:spm_register_regulator() {
    ...
	rdesc = devm_kzalloc(dev, sizeof(*rdesc), GFP_KERNEL);
	if (!rdesc)
		return -ENOMEM;
    ...
	drv->volt_sel = DIV_ROUND_UP(drv->reg_data->init_uV - rdesc->min_uV,
				     rdesc->uV_step);
    ...
}

Because rdesc is allocated using devm_kzalloc(), all of its fields are zero.

Since rdesc->uV_step is never explicitly initialized before this operation,
does it remain 0, causing a panic?

The subsequent call to linear_range_get_selector_high() correctly computes
the selector and overwrites drv->volt_sel.

Is it possible that the older DIV_ROUND_UP() calculation was left in place
by mistake and needs to be removed?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260514-expressatt_cpufreq-v1-0-487fd2d78859@gmail.com?part=2