Re: [PATCH v4 3/3] media: qcom: camss: Add Glymur compatible

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] media: qcom: camss: probe failure on Glymur due to hardcoded CSIPHY resources
--

commit 739b00bed07b519e1dc22bfdfaf2147620cb9dde
Author: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>

media: qcom: camss: Add Glymur compatible

This commit adds a new compatible string "qcom,glymur-camss" for the Glymur
platform. It maps this compatible to x1e80100_resources, since Glymur's
camera subsystem is a functional subset of X1E80100.

> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
> index 23f3cc30a15a5..9954a99981004 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
> @@ -5751,6 +5751,7 @@ static const struct of_device_id camss_dt_match[] = {
>  	{ .compatible = "qcom,sm8550-camss", .data = &sm8550_resources },
>  	{ .compatible = "qcom,sm8650-camss", .data = &sm8650_resources },
>  	{ .compatible = "qcom,x1e80100-camss", .data = &x1e80100_resources },
> +	{ .compatible = "qcom,glymur-camss", .data = &x1e80100_resources },

[Severity: High]
Does this hardcoded resource mapping cause the probe to fail on Glymur hardware?

The commit message notes that Glymur only has three CSIPHY instances,
while X1E80100 has four. Because x1e80100_resources specifies 4 CSIPHY
instances, camss_probe() -> camss_init_subdevices() will unconditionally
execute its initialization loop 4 times:

camss_init_subdevices() {
    ...
    for (i = 0; i < camss->res->csiphy_num; i++) {
        ret = msm_csiphy_subdev_init(camss, &camss->csiphy[i],
    ...
}

During the iteration for the missing instance, msm_csiphy_subdev_init() will
attempt to acquire memory and interrupt resources via
devm_platform_ioremap_resource_byname():

msm_csiphy_subdev_init() {
    ...
    csiphy->base = devm_platform_ioremap_resource_byname(pdev, res->reg[0]);
    if (IS_ERR(csiphy->base))
        return PTR_ERR(csiphy->base);
    ...
}

When this lookup fails on Glymur due to the missing "csiphy2" instance,
won't it propagate an -EINVAL error back to camss_probe(), causing the
entire driver initialization to abort?

>  	{ }
>  };
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260925-glymur_camss-v4-0-d7c2983d6d7b@oss.qualcomm.com?part=3

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy