| Message ID | m3plmhhx6d.fsf@t19.piap.pl (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | PHY: Fix no autoneg corner case | expand |
On Wed, Nov 27, 2024 at 09:56:42AM +0100, Krzysztof Hałasa wrote: > phydev->autoneg appears to indicate if autonegotiation is enabled or > not. Correct. > Unfortunately it's initially set based on the supported capability > rather than the actual hw setting. We need a clear definition of 'initially', and when does it actually matter. Initially, things like speed, duplex and set to UNKNOWN. They don't make any sense until the link is up. phydev->advertise is set to phydev->supported, so that we advertise all the capabilities of the PHY. However, at probe, this does not really matter, it is only when phy_start() is called is the hardware actually configured with what it should advertise, or even if it should do auto-neg or not. In the end, this might not matter. > While in most cases there is no > difference (i.e., autoneg is supported and on by default), certain > adapters (e.g. fiber optics) use fixed settings, configured in hardware. If the hardware is not capable of supporting autoneg, why is autoneg in phydev->supported? To me, that is the real issue here. Andrew
Andrew, Andrew Lunn <andrew@lunn.ch> writes: >> Unfortunately it's initially set based on the supported capability >> rather than the actual hw setting. > > We need a clear definition of 'initially', and when does it actually > matter. > > Initially, things like speed, duplex and set to UNKNOWN. They don't > make any sense until the link is up. phydev->advertise is set to > phydev->supported, so that we advertise all the capabilities of the > PHY. However, at probe, this does not really matter, it is only when > phy_start() is called is the hardware actually configured with what it > should advertise, or even if it should do auto-neg or not. > > In the end, this might not matter. Nevertheless, it seems it does matter. >> While in most cases there is no >> difference (i.e., autoneg is supported and on by default), certain >> adapters (e.g. fiber optics) use fixed settings, configured in hardware. > > If the hardware is not capable of supporting autoneg, why is autoneg > in phydev->supported? To me, that is the real issue here. Well, autoneg *IS* supported by the PHY in this case. No autoneg in phydev->supported would mean I can't enable it if needed, wouldn't it? It is supported but initially disabled. With current code, PHY correctly connects to the other side, all the registers are valid etc., the PHY indicates, for example, a valid link with 100BASE-FX full duplex etc. Yet the Linux netdev, ethtool etc. indicate no valid link, autoneg on, and speed/duplex unknown. It's just completely inconsistent with the real hardware state. It seems the phy/phylink code assumes the PHY starts with autoneg enabled (if supported). This is simply an incorrect assumption. BTW if the code meant to enable autoneg, it would do exactly that - enable it by writing to PHY command register. Then the hw and sw state would be consistent again (though initial configuration would be ignored, not very nice). Now the code doesn't enable autoneg, it only *indicates* it's enabled and in reality it's not.
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c index 366cf3b2cbb0..6858f512558b 100644 --- a/drivers/net/phy/phy_device.c +++ b/drivers/net/phy/phy_device.c @@ -3453,7 +3453,7 @@ static int phy_probe(struct device *dev) struct phy_device *phydev = to_phy_device(dev); struct device_driver *drv = phydev->mdio.dev.driver; struct phy_driver *phydrv = to_phy_driver(drv); - int err = 0; + int err = 0, bmcr; phydev->drv = phydrv; @@ -3495,8 +3495,12 @@ static int phy_probe(struct device *dev) if (err) goto out; + err = bmcr = phy_read(phydev, MII_BMCR); + if (err < 0) + goto out; + if (!linkmode_test_bit(ETHTOOL_LINK_MODE_Autoneg_BIT, - phydev->supported)) + phydev->supported) || !(bmcr & BMCR_ANENABLE)) phydev->autoneg = 0; if (linkmode_test_bit(ETHTOOL_LINK_MODE_1000baseT_Half_BIT,
phydev->autoneg appears to indicate if autonegotiation is enabled or not. Unfortunately it's initially set based on the supported capability rather than the actual hw setting. While in most cases there is no difference (i.e., autoneg is supported and on by default), certain adapters (e.g. fiber optics) use fixed settings, configured in hardware. Now autoneg flag is set only when it's supported and actually used. Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl>