Re: [PATCH v21 07/14] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY - sashiko-bot

From: sashiko-bot@kernel.org
To: "Hangxiang Ma" <hangxiang.ma@oss.qualcomm.com>
Cc: robh@kernel.org, devicetree@vger.kernel.org,
	media-ci@linuxtv.org, neil.armstrong@linaro.org,
	olteanv@gmail.com, vkoul@kernel.org,
	linux-phy@lists.infradead.org, conor+dt@kernel.org
Subject: Re: [PATCH v21 07/14] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY
Date: Mon, 12 Oct 2026 07:07:09 +0000	[thread overview]
Message-ID: <sashiko-outbox-167774@kernel.org> (raw)
In-Reply-To: <20261011-kaanapali-camss-v21-7-04fd28d815c6@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] media: qcom: camss: NULL pointer dereference on malformed DT in legacy PHY fallback
--

commit b51422793e63d50b9c2d85f3e71a49c0f3bb4e69
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>

media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY

Add support for the v2.4.0 two-phase CSIPHY found on Kaanapali, where
the PHY is driven by the standalone phy-qcom-mipi-csi2 DPHY driver
rather than by CAMSS. Add the mipi_csi2_dphy_3nm_kaanapali configuration,
which reuses the x1e80100 lane sequence, clocks and supplies but selects
the v2.4.0 common status offset, adds Kaanapali power domain and register
the "qcom,kaanapali-csi2-phy" compatible.

> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
> index fca3de214a922..eeceb79c1e863 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
> @@ -38,6 +38,51 @@
>  
>  static const struct parent_dev_ops vfe_parent_dev_ops;
>  
> +static const struct camss_subdev_resources csiphy_res_kaanapali[] = {
> +	/* CSIPHY0 */
> +	{
> +		.csiphy = {
> +			.id = 0,
> +			.formats = &csiphy_formats_sdm845
> +		},

[Severity: High]
What happens when a malformed device tree causes the driver to fall back to
legacy PHY mode?

If camss_detect_legacy_phy() encounters missing or differently named remote
endpoints, it defaults to leaving camss->legacy_phy set to true.

When this happens on Kaanapali platforms, camss_init_subdevices() invokes the
legacy initialization path:

drivers/media/platform/qcom/camss/camss.c:camss_init_subdevices() {
    ...
    } else {
        ret = msm_csiphy_subdev_init_legacy(camss,
                                            &camss->csiphy[i],
                                            &res->csiphy_res[i],
    ...
}

This legacy path unconditionally dereferences the hw_ops pointer:

drivers/media/platform/qcom/camss/camss-csiphy.c:msm_csiphy_subdev_init_legacy() {
    ...
    csiphy->res = &res->csiphy;

    ret = csiphy->res->hw_ops->init(csiphy);
    ...
}

Since hw_ops is left uninitialized (NULL) in the Kaanapali definitions, could
this result in a kernel panic during driver probe?

> +	},

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261011-kaanapali-camss-v21-0-04fd28d815c6@oss.qualcomm.com?part=7

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