On 27/10/2025 00:45, Andrew Lunn wrote:
Since the introduction of phylink-managed EEE support in the stmmac driver, EEE is now enabled by default, leading to issues on systems using the DP83867 PHY.
Did you do a bisect to prove this?
Yes, I have done a bisect and the commit that introduced the behavior on our board is 4218647d4556 ("net: stmmac: convert to phylink managed EEE support").
Fixes: 2a10154abcb7 ("net: phy: dp83867: Add TI dp83867 phy")
What has this Fixes: tag got to do with phylink?
I think that the phylink commit is just enabling by default the EEE support, and my commit is not really fixing that. It is why I didn't put a Fixes: tag pointing to that.
I’ve tried to trace the behavior, but it’s quite complex. From my testing, I can summarize the situation as follows:
- ethtool, after that patch, returns: ethtool --show-eee end0 EEE settings for end0: EEE status: enabled - active Tx LPI: 1000000 (us) Supported EEE link modes: 100baseT/Full 1000baseT/Full Advertised EEE link modes: 100baseT/Full 1000baseT/Full Link partner advertised EEE link modes: 100baseT/Full 1000baseT/Full - before that patch returns, after boot: EEE settings for end0: EEE status: disabled Tx LPI: disabled Supported EEE link modes: 100baseT/Full 1000baseT/Full Advertised EEE link modes: Not reported Link partner advertised EEE link modes: 100baseT/Full 1000baseT/Full - Enabling EEE manually using ethtool, triggers the problem too (and ethtool -show-eee report eee status enabled): ethtool --set-eee end0 eee on tx-lpi on ethtool --show-eee end0 EEE settings for end0: EEE status: enabled - active Tx LPI: 1000000 (us) Supported EEE link modes: 100baseT/Full 1000baseT/Full Advertised EEE link modes: 100baseT/Full 1000baseT/Full Link partner advertised EEE link modes: 100baseT/Full 1000baseT/Full
I understand Russell point of view but from my point of view EEE is now enabled by default, and before it wasn't, at least on my setup.
I hope you have seen Russell is not so happy you claim phylink is to blame here...
Andrew
Emanuele