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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <PH0PR11MB59027E7BBF8EF6121DF24DDCF08EA@PH0PR11MB5902.namprd11.prod.outlook.com>
Date: Tue, 13 Jan 2026 12:49:23 +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: Monday, January 12, 2026 4:41 PM

>On Mon, Jan 12, 2026 at 03:01:07PM +0100, Jedrzej Jagielski wrote:
>> Change approach from using EEE enabled flag to using newly introduced
>> enum dedicated to reflect state of the EEE feature.
>> 
>> New enum is required to extend on/off state with new forced off state,
>> which is set when EEE must be temporarily disabled due to unsupported
>> conditions, but should be enabled back when possible.
>> 
>> Such scenario happens eg when link comes up with newly negotiated
>> speed which is not one of the EEE supported link speeds.
>> 
>> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@...el.com>
>> Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@...el.com>
>> ---
>>  drivers/net/ethernet/intel/ixgbe/ixgbe.h         | 11 ++++++++++-
>>  drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c |  4 ++--
>>  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c    |  4 ++--
>>  3 files changed, 14 insertions(+), 5 deletions(-)
>> 
>> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
>> index 14d275270123..9f52da4ec711 100644
>> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
>> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
>> @@ -324,6 +324,14 @@ enum ixgbe_ring_state_t {
>>  	__IXGBE_TX_DISABLED,
>>  };
>>  
>> +enum ixgbe_eee_state_t {
>> +	IXGBE_EEE_DISABLED,	/* EEE explicitly disabled by user */
>> +	IXGBE_EEE_ENABLED,	/* EEE enabled; for E610 it's default state */
>> +	IXGBE_EEE_FORCED_DOWN,	/* EEE disabled by link conditions, try to
>> +				 * restore when possible
>
>This is a bit odd. What generally happens is the PHY advertises what
>it supports. It receives what the link partner advertises. It then
>runs a resolver to determine what the result of the negotiation is,
>and then informs the MAC of the result. The configuration does not
>change if the resolved state means EEE is disabled. The PHY keeps on
>advertising what it was configured with. If the link changes such that
>the resolved state does allow EEE, the notification to the MAC will
>indicate this.
>
>It seems to me you are mixing up configuration and state.
>
>	Andrew

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.