Re: [PATCH v5 4/7] clk: qcom: tcsrcc-glymur: Add Mahua QREF regulator support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing NULL check for the return value of device_get_match_data() before dereferencing it, which will cause a kernel panic if the driver is bound manually via sysfs.
--

commit 8ad3e011a368c7747005c2608d2fded352c89aa2
Author: Qiang Yu <qiang.yu@oss.qualcomm.com>

clk: qcom: tcsrcc-glymur: Add Mahua QREF regulator support

This commit adds Mahua-specific regulator arrays and clock descriptor tables.
It updates the probe function to use match_data to select the correct descriptor
table based on the compatible string.

> diff --git a/drivers/clk/qcom/tcsrcc-glymur.c b/drivers/clk/qcom/tcsrcc-glymur.c
> index e317003398d16..deca9b8794b4f 100644
> --- a/drivers/clk/qcom/tcsrcc-glymur.c
> +++ b/drivers/clk/qcom/tcsrcc-glymur.c
[ ... ]
>  static int tcsr_cc_glymur_probe(struct platform_device *pdev)
>  {
> +	const struct tcsrcc_glymur_data *data = device_get_match_data(&pdev->dev);
> +
>  	return qcom_clk_ref_probe(pdev, &tcsr_cc_glymur_regmap_config,
> -				  tcsr_cc_glymur_clk_descs,
> -				  ARRAY_SIZE(tcsr_cc_glymur_clk_descs));
> +				  data->descs, data->num_descs);

[Severity: High]
Will this cause a NULL pointer dereference if the driver is bound manually via
sysfs?

device_get_match_data() returns NULL when a platform driver is manually bound
to a device via sysfs without a matching OF node. Dereferencing data->descs
and data->num_descs here without checking if data is NULL would lead to a
kernel panic in that scenario.

>  }
>  
>  static struct platform_driver tcsr_cc_glymur_driver = {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260602-tcsr_qref_0527-v5-0-8ea174a59d7e@oss.qualcomm.com?part=4