[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8f976990-1087-4ba0-a06d-c0538c39d2a3@lunn.ch>
Date: Mon, 12 Jan 2026 16:40:38 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Jedrzej Jagielski <jedrzej.jagielski@...el.com>
Cc: intel-wired-lan@...ts.osuosl.org, anthony.l.nguyen@...el.com,
netdev@...r.kernel.org,
Aleksandr Loktionov <aleksandr.loktionov@...el.com>
Subject: Re: [PATCH iwl-next v1 6/7] ixgbe: replace EEE enable flag with
state enum
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
Powered by blists - more mailing lists