Re: [PATCH v12 3/6] media: qcom: camss: Add support to populate sub-devices

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Medium] The return value of `devm_of_platform_populate()` is ignored, leading to silent initialization failures and potential permanent resource leaks.

Pre-existing issues:
- [High] Missing NULL check for the result of `of_device_get_match_data()` leads to a potential NULL pointer dereference.
--

--- Patch [3]: [PATCH v12 3/6] media: qcom: camss: Add support to populate sub-devices ---
commit 187ecc190c79a7e3479de2344bee652ac9f2b71f
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>

media: qcom: camss: Add support to populate sub-devices

This commit updates the Qualcomm Camera Subsystem (CAMSS) probe function
to use devm_of_platform_populate() for populating sub-devices in the tree.

> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
> index 2123f6388e3d7..95e655a8b6aa0 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
[ ... ]
> @@ -5362,6 +5363,8 @@ static int camss_probe(struct platform_device *pdev)
>  	if (!camss)
>  		return -ENOMEM;
>  
> +	devm_of_platform_populate(dev);

[Severity: Medium]
Should the return value of devm_of_platform_populate() be checked here?

When this function fails, it returns a negative error code and the devres
framework frees the associated devres action rather than attaching it to the
parent device.

If the population fails midway, could this leave successfully created child
devices dangling, resulting in a permanent resource leak upon device unbind?

> +
>  	camss->res = of_device_get_match_data(dev);

[Severity: High]
This is a pre-existing issue, but is it possible for
of_device_get_match_data() to return NULL here?

If the driver is bound via sysfs to a platform device that lacks an OF node
(for instance, one manually created and bound by root),
of_device_get_match_data() will return NULL.

Would this lead to a NULL pointer dereference shortly after this line when
accessing camss->res->csiphy_num during the csiphy allocation?

>  
>  	atomic_set(&camss->ref_count, 0);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260708-b4-linux-next-25-03-13-dtsi-x1e80100-camss-v12-0-f8588da41f16@linaro.org?part=3