netdev - [PATCH RFC net-next 00/22] net: stmmac/xpcs: further EEE work

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]

Message-ID: <Z5j7yCYSsQ7beznD@shell.armlinux.org.uk>
Date: Tue, 28 Jan 2025 15:46:16 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>
Cc: Alexandre Torgue <alexandre.torgue@...s.st.com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>,
	Jiawen Wu <jiawenwu@...stnetic.com>,
	linux-arm-kernel@...ts.infradead.org,
	linux-stm32@...md-mailman.stormreply.com,
	Maxime Coquelin <mcoquelin.stm32@...il.com>, netdev@...r.kernel.org,
	Paolo Abeni <pabeni@...hat.com>,
	Vladimir Oltean <olteanv@...il.com>
Subject: [PATCH RFC net-next 00/22] net: stmmac/xpcs: further EEE work

Hi,

This series is a preview of the further work I wish to merge during
the next cycle for EEE in stmmac and XPCS drivers.

The first 14 patches target stmmac's EEE implementation, which I believe
to be buggy such that it does not disable LPI signalling immediately
when ethtool settings change, but instead in effect waits until the
next packet is sent. This is a relatively minor bug, so isn't high
priority.

However, what the first set of patches are doing is continuing the
cleanup of the stmmac implementation and making things consistent and
readable.

The following patches are aimed at eliminating the xpcs_config_eee()
direct call between stmmac's EEE code and XPCS, and present a way to
do this. Sadly, it doesn't reduce the number of direct calls between
these two drivers as we need to implement a new call to configure the
"mult_fract" parameter in the XPCS EEE control registers, which is
supposed to be derived from the speed of an EEE-specific clock.

However, I remain unconvinced whether it is necessary to enable and
disable the EEE controls at the XPCS with LPI being enabled/disabled
at the MAC. Could many or all of these settings be configured as part
of the creation of the driver instance instead?

Without knowing that, the only real way to clean this up is the one
I've taken - which is the principle of preserving the existing
behaviour.

Sadly, the entire series doesn't lead to a great reduction in LOC,
however, the initial 14 stmmac patches leads to a reduction of 71
LOC.

My plan is to send the first 14 patches shortly after net-next opens.

 drivers/net/ethernet/stmicro/stmmac/common.h       |  14 +++
 drivers/net/ethernet/stmicro/stmmac/dwmac1000.h    |  13 +--
 .../net/ethernet/stmicro/stmmac/dwmac1000_core.c   |  30 ++---
 drivers/net/ethernet/stmicro/stmmac/dwmac4.h       |  12 +-
 drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c  |  96 +++++++---------
 drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h     |   9 +-
 .../net/ethernet/stmicro/stmmac/dwxgmac2_core.c    |  49 ++++----
 drivers/net/ethernet/stmicro/stmmac/hwif.h         |  21 ++--
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  | 126 +++++++--------------
 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c  |   2 +
 drivers/net/pcs/pcs-xpcs.c                         |  89 ++++++++++-----
 drivers/net/pcs/pcs-xpcs.h                         |   1 +
 drivers/net/phy/phylink.c                          |  25 +++-
 include/linux/pcs/pcs-xpcs.h                       |   3 +-
 include/linux/phylink.h                            |  22 ++++
 15 files changed, 253 insertions(+), 259 deletions(-)

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