Re: [PATCH net-next v3 4/5] net: phy: maxio: parse and enable PHY clock from generic DT binding

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] net: phy: maxio: PHY clock enabled after reset deassertion without subsequent reset cycle
- [High] net: phy: maxio: returning -EPROBE_DEFER causes permanent genphy hijacking
- [Medium] net: phy: maxio: missing clock stabilization delay causes unsafe early MDIO access
--

commit 52dca313fd23831811c2761895faceaea5529795
Author: Andre Przywara <andre.przywara@arm.com>

net: phy: maxio: parse and enable PHY clock from generic DT binding

The generic PHY DT binding features a clocks property, which describes
the clock input to the PHY. This commit looks for a "clocks" property
inside the PHY node and enables that clock explicitly during probe,
allowing boards with a SoC-driven PHY clock to use the PHY.

> diff --git a/drivers/net/phy/maxio.c b/drivers/net/phy/maxio.c
> index 9ba82c1cd8b13..266be95b949a8 100644
> --- a/drivers/net/phy/maxio.c
> +++ b/drivers/net/phy/maxio.c

[ ... ]

> @@ -57,6 +59,11 @@ static int maxio_mae0621a_probe(struct phy_device *phydev)
>  		priv->clk_out_125m = true;
>  	}
>  
> +	/* PHY clock from the generic PHY binding */
> +	priv->clk = devm_clk_get_optional_enabled(&phydev->mdio.dev, NULL);

[Severity: High]
Does this miss a hardware reset cycle?

The framework calls phy_device_reset(phydev, 0) in phy_probe() before invoking
phydev->drv->probe. By enabling the clock here after the reset is already
deasserted, the PHY misses its proper reset sequence.

Should this issue a subsequent reset cycle (phy_device_reset(phydev, 1)
followed by phy_device_reset(phydev, 0)) to correctly initialize the PHY
with the newly running clock?

> +	if (IS_ERR(priv->clk))
> +		return PTR_ERR(priv->clk);

[Severity: High]
If this returns -EPROBE_DEFER, will it cause permanent genphy hijacking?

If devm_clk_get_optional_enabled() defers, the PHY device is left on the
deferred probe list with dev->driver = NULL. If the MAC driver subsequently
probes and calls phy_attach_direct(), the core code sees !d->driver and
forcefully binds genphy_driver.

This would bypass this driver completely and prevent the required clock from
being enabled, leaving the PHY permanently dead until reboot.

> +
> +	return 0;

[Severity: Medium]
Is a clock stabilization delay needed here before returning?

The probe routine returns immediately after clock enablement. The PHY
framework will then instantly issue MDIO read/write commands (e.g.,
phy_disable_interrupts()).

Since external oscillators and internal PHY PLLs require physical stabilization
time, could accessing the PHY registers before the clock stabilizes lead to
MDIO timeouts or corrupted reads?

>  }
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260926225625.25969-1-andre.przywara@arm.com?part=4