From: Andrew Lunn <[email protected]> Sent: Tuesday, January 13, 2026 3:16 PM
>> OK, so you mean it's redundant? There's no need to explicitly state that >> EEE needs to be disabled when it i not capable of beeing still on due >> to unsupported link conditions? >> Probably i would need to check how E610 behaves in such scenario. > >It would depend on what your firmware is doing, but if it is >implemented correctly, there should not be any need to change the >configuration. ethtool_keee->eee_active should indicate the status of >the negotiation. If you are in a link mode which does not support EEE, >so it is turned off in the MAC, set it to false. supported_eee, >advertising_eee lp_advertised should not care about the current link >mode or the value of eee_active. > >And you probably want to check for how phylink and phylib handle this, >since they are the most used implementation and so the reference. > > Andrew > i've checked the scenario and, indeed, EEE gets reenabled once link conditions are meet again even without driver intervention. Thanks for pointing me that. In that case i will remove link enablement/disablement on driver side, but i am wondering whether leaving logging trace on link condition change (EEE gets disabled due to unsupported link conditions) would be beneficial WDUT? then keeping tristate EEE would be required i believe
