On Wed, Dec 18, 2024 at 06:59:09PM -0800, Jakub Kicinski wrote: > On Tue, 17 Dec 2024 11:43:11 +0100 Andrew Lunn wrote: > > > @@ -2071,6 +2071,7 @@ void phy_advertise_eee_all(struct phy_device *phydev); > > > void phy_support_sym_pause(struct phy_device *phydev); > > > void phy_support_asym_pause(struct phy_device *phydev); > > > void phy_support_eee(struct phy_device *phydev); > > > +void phy_disable_eee(struct phy_device *phydev); > > > > So we have three states: > > > > MAC tells PHYLIB it does support EEE > > MAC tells PHYLIB it does not support EEE > > MAC says nothing. > > > > Do we really want this? > > Hi Andrew, do you feel convinced? I think I messed up merging some EEE > patches recently, an explicit Ack would boost my confidence.. For phylib, yes, we have to live with this unknown state. so these patches are O.K. For phylink, i would like Russells opinion. It would be better if we could avoid having the third state. Maybe we need a couple of cycles where if the MAC says nothing, but the PHY negotiates EEE, we issue a warning? We might then get an idea of how many systems are in this unknown category, and can encourage MAC driver Maintainers to add the missing EEE support. Russell? Andrew
