[PATCH v4 4/5] phy: phy-can-transceiver: Don't check for specific errors when parsing properties

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] The driver unconditionally fails or crashes due to incorrect checking of `drvdata`.
--

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

phy: phy-can-transceiver: Don't check for specific errors when parsing properties

This commit modifies the max-bitrate property parsing to check for the
property existence first before attempting to read it. It applies a default
value if the property is missing, rather than relying on specific error
codes.

> diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
> index 23655956ace80..973cc7ce651fb 100644
> --- a/drivers/phy/phy-can-transceiver.c
> +++ b/drivers/phy/phy-can-transceiver.c
> @@ -128,8 +128,9 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
>  	struct gpio_desc *standby_gpio;
>  	struct gpio_desc *enable_gpio;
>  	struct mux_state *mux_state;
> -	u32 max_bitrate = 0;
>  	int err, i, num_ch = 1;
> +	const char *propname;
> +	u32 max_bitrate;
>  
>  	drvdata = device_get_match_data(dev);
>  	if (drvdata)

I noticed a potential issue in the context of this diff. Is the check for
drvdata inverted here? This logic appears to have been introduced by a
previous patch in the series.

If device_get_match_data() successfully finds match data, the probe function
aborts and returns -ENODEV. If no match data is found, drvdata is NULL and
the function proceeds, which leads to a dereference on the next check:

	drvdata = device_get_match_data(dev);
	if (drvdata)
		return -ENODEV;

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

Could this cause the driver to fail on valid probes, or dereference a NULL
pointer when match data is missing?

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