[PATCH v4 3/5] phy: phy-can-transceiver: Move OF ID table closer to their user

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] The check `if (drvdata)` incorrectly returns `-ENODEV` when match data is found, and leads to a NULL pointer dereference when match data is missing.
--

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

phy: phy-can-transceiver: Move OF ID table closer to their user

This commit moves the can_transceiver_phy_ids table closer to its
user at the end of the file.

> diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
> index 5cfd097352048..23655956ace80 100644
> --- a/drivers/phy/phy-can-transceiver.c
> +++ b/drivers/phy/phy-can-transceiver.c

[ ... ]

This regression wasn't introduced by this patch, but by a previous
commit in the series ("phy: phy-can-transceiver: use
device_get_match_data()").

Looking at can_transceiver_phy_probe(), does this code correctly handle the
match data?

drivers/phy/phy-can-transceiver.c:can_transceiver_phy_probe() {
    ...
	drvdata = device_get_match_data(dev);
	if (drvdata)
		return -ENODEV;

	if (drvdata->flags & CAN_TRANSCEIVER_DUAL_CH)
    ...
}

It appears that if match data is successfully found, the probe will return
-ENODEV.

Conversely, if no match data is found, the condition evaluates to false,
and execution proceeds to dereference the NULL drvdata pointer.

Should the condition be changed to check for !drvdata instead?

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