Re: [PATCH 2/5] ARM: dts: imx6ull-tarragon-common: Fix Ethernet PHY issues

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] dts: Missing PHY ID in compatible string causes PHY probe failure
- [High] dts: PHY reset pinctrl applied too late due to PHY node placement
- [Medium] dts: PHY reset duration drastically reduced from 25ms to 500us
--

commit f2c57a8f69beb5f6e98a9a695928883c23235853
Author: Stefan Wahren <wahrenst@gmx.net>
ARM: dts: imx6ull-tarragon-common: Fix Ethernet PHY issues

This commit moves the SMSC LAN8710 Ethernet PHY reset handling to the
generic PHY reset properties on the Tarragon platform.

[Severity: High]
In arch/arm/boot/dts/nxp/imx/imx6ull-tarragon-common.dtsi, the ethphy0
node at line 131 sets the compatible string to ethernet-phy-ieee802.3-c22.
Does this missing explicit PHY ID cause the MDIO core to fail device
creation?

When the MDIO bus is registered, fwnode_mdiobus_register_phy in
drivers/net/mdio/fwnode_mdio.c (around line 132) will try to parse the PHY
ID from the compatible string. If it fails, it falls back to
get_phy_device to read the ID directly from the MDIO bus. Since the PHY is
still held in hardware reset during this read, it will receive 0xffff and
return -ENODEV. The generic PHY reset logic runs after the PHY device is
created, creating a chicken-and-egg situation where the PHY is never
detected.

[Severity: High]
In arch/arm/boot/dts/nxp/imx/imx6ull-tarragon-common.dtsi, moving the
pinctrl_enet1_phy_rst from the fec1 node (line 114) to the ethphy0 node
(line 130) appears to apply the pinctrl too late.

Could this cause the PHY reset GPIO pad to remain unconfigured during the
initial MDIO device registration reset sequence? The Linux driver core
applies pinctrl state just before the device probe binds. However, the
MDIO core initial hardware reset pulse happens before the PHY device is
added and bound to a driver. Since the i.MX pinctrl driver does not
implement gpio_request_enable, requesting the GPIO does not automatically
mux the pin in hardware, causing the reset pulse to be swallowed and
leading to initialization failures on cold boots.

[Severity: Medium]
In arch/arm/boot/dts/nxp/imx/imx6ull-tarragon-common.dtsi, the previous
phy-reset-duration on the fec1 node at line 118 was 25 milliseconds. The
new reset-assert-us and reset-deassert-us properties on the ethphy0 node
at line 137 are 500 microseconds.

Can this 50x reduction in reset duration violate the PHY hardware timing
requirements and cause intermittent link negotiation failures? It looks
like the units might have been confused between milliseconds and
microseconds when migrating these properties.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261004140123.46461-1-wahrenst@gmx.net?part=2