netdev - [PATCH RFC net-next 0/4] phylink EEE support

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-next>] [day] [month] [year] [list]

Date: Fri, 9 Jun 2023 10:11:05 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Marcin Wojtas <mw@...ihalf.com>,
	netdev@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: [PATCH RFC net-next 0/4] phylink EEE support

Hi,

There has been some recent discussion on generalising EEE support so
that drivers implement it more consistently. This has mostly focused
around phylib, but there are other situations where EEE may be useful.

To illustrate this, in both USGMII and UXGMII communicate EEE through
the configuration word - bit 8 indicates EEE capability and bit 7
indicates the clock stop capability. The PHY may not be accessible.
Another case would be a PHY on a SFP module that may not be accessible,
signalling LPI to it may result in power savings if it has negotiated
with the link partner. My understanding is that signalling LPI when
negotiation hasn't agreed EEE support should be fine. In the classic
model, LPI informs the PHY that the MAC is idle, and gives it
permission to enter low power. It will only enter low power when the
MAC sends LPI and the remote PHY also agrees to enter low power.

mvneta has had EEE support for a while, but the implementation has its
quirks. This series implements EEE handling in phylink. To make use of
it, a MAC driver needs to fill in the default parameters for EEE, and
provide the enable and disable functions for LPI.

This series also adds EEE for mvpp2, which is only supported by the
GMAC (up to 1G) and not the XLG (5G,10G) MAC.

There is further work that needs to be considered - 802.3 has the
facility to negotiate the Tw (wake to data) parameter via packets.
Also, timing parameters are speed and media type specific, some
implementations need these parameters reprogrammed each time the speed
changes (e.g. mvneta and mvpp2.)

Patch 1 adds a structure to store the runtime EEE configuration  state,
a helper to decode the state to indicate whether LPI can be enabled (it
remains the responsibility of the user to determine whether EEE has
been negotiated.) A couple of helpers are provided to insert and
extract the EEE configuration from the ethtool EEE structure.

Patch 2 adds the phylink implementation.

Patch 3 converts mvneta to use phylink's implementation.

Patch 4 adds mvpp2 support.

This uses the current code from phylib, and is only functional when we
have a phylib PHY, but can be easily extended so that when we have a
SFP socket without a PHY, we can enable LPI signalling.

 drivers/net/ethernet/marvell/mvneta.c           | 95 ++++++++++++++++---------
 drivers/net/ethernet/marvell/mvpp2/mvpp2.h      |  5 ++
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 85 ++++++++++++++++++++++
 drivers/net/phy/phylink.c                       | 82 +++++++++++++++++++--
 include/linux/phylink.h                         | 32 +++++++++
 include/net/eee.h                               | 38 ++++++++++
 6 files changed, 298 insertions(+), 39 deletions(-)
 create mode 100644 include/net/eee.h

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!