Re: [PATCH net-next v7 2/2] net: phy: add X-Powers AC200/AC300 EPHY driver

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Using device_trylock() with a fallback to -EPROBE_DEFER creates a fragile retry loop that can lead to permanent probe failures.
--

--- Patch [2]: [PATCH net-next v7 2/2] net: phy: add X-Powers AC200/AC300 EPHY driver ---
commit 51ec613693f83307bdc7a40a8e3f884bbf572129
Author: James Hilliard <[email protected]>
Subject: net: phy: add X-Powers AC200/AC300 EPHY driver

This commit adds a new Ethernet PHY driver for the X-Powers AC200 and AC300
companion ICs. It configures shared MDIO registers along with
package-specific I2C or MDIO control registers.

> diff --git a/drivers/net/phy/xpowers/ac200.c b/drivers/net/phy/xpowers/ac200.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/net/phy/xpowers/ac200.c
[ ... ]
> +struct acx00_ephy_control *
> +ac200_ephy_ctl_create(struct phy_device *phydev,
> +		      struct device_node *package_node,
> +		      bool has_calibration, u8 calibration)
> +{
[ ... ]
> +	if (!device_link_add(dev, &client->dev,
> +			     DL_FLAG_AUTOREMOVE_CONSUMER)) {
> +		ret = dev_err_probe(dev, -EINVAL,
> +				    "failed to link AC200 device\n");
> +		goto out_put_client;
> +	}
> +
> +	if (!device_trylock(&client->dev)) {
> +		ret = dev_err_probe(dev, -EPROBE_DEFER,
> +				    "AC200 driver is not ready\n");
> +		goto out_put_client;
> +	}

[Severity: Medium]
Could this trylock and deferral pattern lead to permanent probe failures?

If the AC200 device is already fully bound, but its device lock is temporarily
held by another thread (such as a concurrent sysfs attribute read or a PM 
suspend/resume operation) when the PHY driver probes, device_trylock() will
fail.

This causes the PHY driver to return -EPROBE_DEFER. However, because the
supplier AC200 device is already bound, it will not trigger a new bind event.
If no other devices bind in the system to kick the deferred probe workqueue,
the PHY could remain permanently unbound.

Is there a way to avoid this fragile retry loop, perhaps by using standard
locking instead of treating transient lock contention as a missing
dependency?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2