netdev - RE: [PATCH iwl-next v1 6/7] ixgbe: replace EEE enable flag with state enum

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <MW4PR11MB589023306C8055BD6A937557F088A@MW4PR11MB5890.namprd11.prod.outlook.com>
Date: Mon, 19 Jan 2026 08:45:12 +0000
From: "Jagielski, Jedrzej" <jedrzej.jagielski@...el.com>
To: Andrew Lunn <andrew@...n.ch>
CC: "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
	"Nguyen, Anthony L" <anthony.l.nguyen@...el.com>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "Loktionov, Aleksandr"
	<aleksandr.loktionov@...el.com>
Subject: RE: [PATCH iwl-next v1 6/7] ixgbe: replace EEE enable flag with state
 enum

From: Andrew Lunn <andrew@...n.ch> 
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