[PATCH v5 phy-next 02/16] phy: lynx-28g: reject probing on devices with unsupported OF nodes

[sashiko-bot at kernel.org]

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

Pre-existing issues:
- [High] Missing check for the return value of `of_device_get_match_data()` in `imx8_pcie_phy_probe` and `imx_hsio_probe` leads to NULL pointer dereference.
--

commit 11cd1431079ad06a01704502129a0983e1f3e992
Author: Vladimir Oltean <vladimir.oltean at nxp.com>

phy: lynx-28g: reject probing on devices with unsupported OF nodes

This commit fixes a potential NULL pointer dereference in the lynx-28g
driver when bound to arbitrary devices via driver_override. It adds a
check to ensure of_device_get_match_data() does not return NULL before
dereferencing the match data.

> diff --git a/drivers/phy/freescale/phy-fsl-lynx-28g.c b/drivers/phy/freescale/phy-fsl-lynx-28g.c
> index cacc128dc96a1..1f5cb02931f56 100644
> --- a/drivers/phy/freescale/phy-fsl-lynx-28g.c
> +++ b/drivers/phy/freescale/phy-fsl-lynx-28g.c
> @@ -1477,6 +1477,9 @@ static int lynx_28g_probe(struct platform_device *pdev)
>  
>  	priv->dev = dev;
>  	priv->info = of_device_get_match_data(dev);
> +	if (!priv->info)
> +		return -ENODEV;
> +
>  	dev_set_drvdata(dev, priv);

[Severity: High]
This isn't a bug introduced by this patch, but it appears the exact same
missing check exists in other drivers within the same subsystem.

Do we need to add similar NULL checks for of_device_get_match_data() in
imx8_pcie_phy_probe() to avoid a crash?

drivers/phy/freescale/phy-fsl-imx8m-pcie.c:imx8_pcie_phy_probe() {
    ...
    imx8_phy->drvdata = of_device_get_match_data(dev);
    ...
    imx8_phy->iomuxc_gpr =
         syscon_regmap_lookup_by_compatible(imx8_phy->drvdata->gpr);
    ...
}

And also in imx_hsio_probe() where it accesses the lane_num field?

drivers/phy/freescale/phy-fsl-imx8qm-hsio.c:imx_hsio_probe() {
    ...
    priv->drvdata = of_device_get_match_data(dev);
    ...
    for (i = 0; i < priv->drvdata->lane_num; i++) {
    ...
}

Without a check, could these drivers similarly crash with a NULL pointer
dereference when bound to a device with a different compatible string via
the driver_override interface?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260610151952.2141019-1-vladimir.oltean@nxp.com?part=2