[PATCH v4 2/5] phy: phy-can-transceiver: use device_get_match_data()

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The error check for `device_get_match_data(dev)` is inverted, causing the driver probe to fail on success and triggering a NULL pointer dereference on failure.
--

commit f9915d9d74989682b2b7e20d67129e0dd4abdab9
Author: Andy Shevchenko <andriy.shevchenko at linux.intel.com>

phy: phy-can-transceiver: use device_get_match_data()

This commit transitions the driver to use the generic firmware node interface
for retrieving device match data instead of the OF-specific one. It also drops
the unneeded device node argument from devm_phy_create().

> diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
> index 1808f903c0570..5cfd097352048 100644
> --- a/drivers/phy/phy-can-transceiver.c
> +++ b/drivers/phy/phy-can-transceiver.c
[ ... ]
> @@ -152,7 +152,6 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
>  	struct can_transceiver_phy *can_transceiver_phy;
>  	struct can_transceiver_priv *priv;
>  	const struct can_transceiver_data *drvdata;
> -	const struct of_device_id *match;
>  	struct phy *phy;
>  	struct gpio_desc *silent_gpio;
>  	struct gpio_desc *standby_gpio;
> @@ -161,11 +160,10 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
>  	u32 max_bitrate = 0;
>  	int err, i, num_ch = 1;
>  
> -	match = of_match_node(can_transceiver_phy_ids, pdev->dev.of_node);
> -	if (!match || !match->data)
> +	drvdata = device_get_match_data(dev);
> +	if (drvdata)
>  		return -ENODEV;

Does this invert the error check? 

When device_get_match_data() successfully returns valid match data, it looks
like this condition will evaluate to true and erroneously abort the probe with
-ENODEV.

>  
> -	drvdata = match->data;
>  	if (drvdata->flags & CAN_TRANSCEIVER_DUAL_CH)
>  		num_ch = 2;

Conversely, if device_get_match_data() fails and returns NULL, won't the 
probe continue and cause a NULL pointer dereference when evaluating 
drvdata->flags here?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260512130552.272476-1-andriy.shevchenko@linux.intel.com?part=2