Re: [PATCH 2/2] soc: qcom: socinfo: add few more SOC IDs for IPQ5210 family

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] qcom-cpufreq: kernel panic on boot for new IPQ5210 SoCs
--

commit 9ff7f8e096f96a22381e41ab225a2e460fe769da
Author: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>

soc: qcom: socinfo: add few more SOC IDs for IPQ5210 family

QCF3211 and IPQ5211 are the new SoCs based on the IPQ5210 family. This commit
adds the SoC IDs for them to the socinfo driver.

> diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
> index 63ee5cd561a29..4e7e14fe72317 100644
> --- a/drivers/soc/qcom/socinfo.c
> +++ b/drivers/soc/qcom/socinfo.c
> @@ -558,6 +558,8 @@ static const struct soc_id soc_id[] = {
>  	{ qcom_board_id(IPQ9630) },
>  	{ qcom_board_id(IPQ9640) },
>  	{ qcom_board_id(IPQ9670) },
> +	{ qcom_board_id(QCF3211) },
> +	{ qcom_board_id(IPQ5211) },

[Severity: High]
Could this lead to a kernel panic during boot on these new SoCs? 

When the qcom-cpufreq-nvmem driver probes, it calls
qcom_cpufreq_kryo_name_version() which checks the SoC ID. Since QCOM_ID_QCF3211
and QCOM_ID_IPQ5211 are not handled in its switch statement, execution
appears to fall through to the default case:

drivers/cpufreq/qcom-cpufreq-nvmem.c:qcom_cpufreq_kryo_name_version() {
...
	switch (msm_id) {
...
	case QCOM_ID_IPQ5200:
	case QCOM_ID_IPQ5210:
	case QCOM_ID_QCF2200:
	case QCOM_ID_QCF3200:
	case QCOM_ID_QCF3210:
		drv->versions = (*speedbin == 0xcd) ? BIT(1) : BIT(0);
		break;
...
	default:
		BUG();
		break;
	}
...
}

Does qcom-cpufreq-nvmem.c need to be updated alongside this change to handle
the newly added IDs and prevent triggering this BUG() trap?

>  };
>  
>  static const char *socinfo_machine(struct device *dev, unsigned int id)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260921-ipq52xx_new_ids-v1-0-63d68a11bbff@oss.qualcomm.com?part=2