Add Energy Efficient Ethernet (IEEE 802.3az) support to the Cadence GEM
(macb) driver using phylink's managed EEE framework. The GEM MAC has
hardware LPI registers but no built-in idle timer, so the driver
implements software-managed TX LPI using a delayed_work timer while
delegating EEE negotiation and ethtool state to phylink.
Changes from v2:
- macb_tx_lpi_set() now returns bool indicating whether the register
value actually changed, avoiding redundant writes.
- Removed tx_lpi_enabled field from struct macb; LPI state is tracked
entirely within the spinlock-protected register read/modify/write.
- macb_tx_lpi_wake() uses the return value of macb_tx_lpi_set() to
skip the cancel/udelay when TXLPIEN was already clear.
All changes based on feedback from Russell King.
Changes from v1:
- Rewrote to use phylink managed EEE (mac_enable_tx_lpi /
mac_disable_tx_lpi callbacks) instead of the obsolete
phy_init_eee() approach, as recommended by Russell King.
- ethtool get_eee/set_eee are now pure phylink passthroughs.
- Removed all manual EEE state tracking from mac_link_up/down;
phylink handles the lifecycle.
The series is structured as follows:
1. Register definitions: LPI counter offsets (0x270-0x27c), TXLPIEN
bitfield (NCR bit 19), and MACB_CAPS_EEE capability flag.
2. LPI statistics: Expose the four hardware EEE counters (RX/TX LPI
transitions and time) through ethtool -S, accumulated in software
since they are clear-on-read.
3. TX LPI engine: phylink mac_enable_tx_lpi / mac_disable_tx_lpi
callbacks with a delayed_work-based idle timer. LPI entry is
deferred 1 second after link-up per IEEE 802.3az. Wake before
transmit with a conservative 50us PHY wake delay.
4. ethtool EEE ops: get_eee/set_eee delegating to phylink for PHY
negotiation and timer management.
5. RP1 enablement: Set MACB_CAPS_EEE for the Raspberry Pi 5's RP1
southbridge (Cadence GEM_GXL rev 0x00070109 + BCM54213PE PHY).
Tested on Raspberry Pi 5 (1000BASE-T, BCM54213PE PHY, 250ms LPI timer):
iperf3 throughput (no regression):
TCP TX: 937.8 Mbit/s (EEE on) vs 937.0 Mbit/s (EEE off)
TCP RX: 936.5 Mbit/s both
Latency (ping RTT, small expected increase from LPI wake):
1s interval: 0.273 ms (EEE on) vs 0.181 ms (EEE off)
10ms interval: 0.206 ms (EEE on) vs 0.168 ms (EEE off)
flood ping: 0.200 ms (EEE on) vs 0.156 ms (EEE off)
LPI counters (ethtool -S, 1s-interval ping, EEE on):
tx_lpi_transitions: 112
tx_lpi_time: 15574651
Zero packet loss across all tests. Also verified with
ethtool --show-eee / --set-eee and cable unplug/replug cycling.
Nicolai Buchwitz (5):
net: cadence: macb: add EEE register definitions and capability flag
net: cadence: macb: add EEE LPI statistics counters
net: cadence: macb: implement EEE TX LPI support
net: cadence: macb: add ethtool EEE support
net: cadence: macb: enable EEE for Raspberry Pi RP1
drivers/net/ethernet/cadence/macb.h | 20 ++++
drivers/net/ethernet/cadence/macb_main.c | 136 ++++++++++++++++++++++-
2 files changed, 155 insertions(+), 1 deletion(-)
--
2.51.0
Expose the GEM MAC's EEE Low Power Idle hardware counters through
ethtool -S:
- rx_lpi_transitions: number of RX LPI entry events
- rx_lpi_time: cumulative time spent in RX LPI
- tx_lpi_transitions: number of TX LPI entry events (TXLPIEN 0->1)
- tx_lpi_time: cumulative time in TX LPI
These are clear-on-read hardware registers at offsets 0x270-0x27c,
automatically collected by the existing gem_statistics read loop.
Signed-off-by: Nicolai Buchwitz <redacted>
---
drivers/net/ethernet/cadence/macb.h | 8 ++++++++
1 file changed, 8 insertions(+)
@@ -1050,6 +1050,10 @@ struct gem_stats {u64rx_ip_header_checksum_errors;u64rx_tcp_checksum_errors;u64rx_udp_checksum_errors;+u64rx_lpi_transitions;+u64rx_lpi_time;+u64tx_lpi_transitions;+u64tx_lpi_time;};/* Describes the name and offset of an individual statistic register, as
Implement Energy Efficient Ethernet TX Low Power Idle using phylink's
managed EEE framework. The Cadence GEM MAC has no built-in idle timer
— TXLPIEN (NCR bit 19) immediately blocks all TX when set and the MAC
does NOT auto-wake — so the driver uses a software delayed_work timer
for idle detection.
The TX LPI lifecycle:
- phylink calls mac_enable_tx_lpi() after link-up with the negotiated
timer value. The driver defers the first LPI entry by 1 second per
IEEE 802.3az section 22.7a.
- macb_tx_complete() reschedules the idle timer after each TX drain.
- macb_start_xmit() wakes from LPI by clearing TXLPIEN, cancelling
the pending work, and waiting 50us (conservative Tw_sys) before
initiating the transmit.
- phylink calls mac_disable_tx_lpi() before link-down, which cancels
the work and clears TXLPIEN.
The phylink_config is populated with LPI capabilities (MII, GMII, RGMII
modes; 100FD and 1000FD speeds) and a 250ms default idle timer, gated
on MACB_CAPS_EEE.
Signed-off-by: Nicolai Buchwitz <redacted>
---
drivers/net/ethernet/cadence/macb.h | 5 +
drivers/net/ethernet/cadence/macb_main.c | 111 +++++++++++++++++++++++
2 files changed, 116 insertions(+)
@@ -589,6 +590,93 @@ static const struct phylink_pcs_ops macb_phylink_pcs_ops = {.pcs_config=macb_pcs_config,};+staticboolmacb_tx_lpi_set(structmacb*bp,boolenable)+{+unsignedlongflags;+u32old,ncr;++spin_lock_irqsave(&bp->lock,flags);+old=ncr=macb_readl(bp,NCR);+if(enable)+ncr|=GEM_BIT(TXLPIEN);+else+ncr&=~GEM_BIT(TXLPIEN);+if(old!=ncr)+macb_writel(bp,NCR,ncr);+spin_unlock_irqrestore(&bp->lock,flags);++returnold!=ncr;+}++staticboolmacb_tx_all_queues_idle(structmacb*bp)+{+unsignedintq;++for(q=0;q<bp->num_queues;q++){+structmacb_queue*queue=&bp->queues[q];++if(queue->tx_head!=queue->tx_tail)+returnfalse;+}+returntrue;+}++staticvoidmacb_tx_lpi_work_fn(structwork_struct*work)+{+structmacb*bp=container_of(work,structmacb,tx_lpi_work.work);++if(bp->eee_active&&macb_tx_all_queues_idle(bp))+macb_tx_lpi_set(bp,true);+}++staticvoidmacb_tx_lpi_schedule(structmacb*bp)+{+if(bp->eee_active)+mod_delayed_work(system_wq,&bp->tx_lpi_work,+usecs_to_jiffies(bp->tx_lpi_timer));+}++/* Wake from LPI before transmitting. The MAC must deassert TXLPIEN+*andwaitforthePHYtoexitLPIbeforeanyframecanbesent.+*IEEE802.3azTw_sysis~17usfor1000BASE-T,~30usfor100BASE-TX;+*weuseaconservative50us.+*/+staticvoidmacb_tx_lpi_wake(structmacb*bp)+{+if(!macb_tx_lpi_set(bp,false))+return;++cancel_delayed_work(&bp->tx_lpi_work);+udelay(50);+}++staticvoidmacb_mac_disable_tx_lpi(structphylink_config*config)+{+structnet_device*ndev=to_net_dev(config->dev);+structmacb*bp=netdev_priv(ndev);++bp->eee_active=false;+cancel_delayed_work_sync(&bp->tx_lpi_work);+macb_tx_lpi_set(bp,false);+}++staticintmacb_mac_enable_tx_lpi(structphylink_config*config,u32timer,+booltx_clk_stop)+{+structnet_device*ndev=to_net_dev(config->dev);+structmacb*bp=netdev_priv(ndev);++bp->tx_lpi_timer=timer;+bp->eee_active=true;++/* Defer initial LPI entry by 1 second after link-up per+*IEEE802.3azsection22.7a.+*/+mod_delayed_work(system_wq,&bp->tx_lpi_work,msecs_to_jiffies(1000));++return0;+}+staticvoidmacb_mac_config(structphylink_config*config,unsignedintmode,conststructphylink_link_state*state){
From: Sai Krishna Gajula <hidden> Date: 2026-02-25 17:32:59
quoted hunk
-----Original Message-----
From: Nicolai Buchwitz <redacted>
Sent: Wednesday, February 25, 2026 2:46 PM
To: netdev@vger.kernel.org
Cc: andrew+netdev@lunn.ch; claudiu.beznea@tuxon.dev;
davem@davemloft.net; edumazet@google.com; kuba@kernel.org;
nicolas.ferre@microchip.com; pabeni@redhat.com; linux@armlinux.org.uk;
phil@raspberrypi.com; Nicolai Buchwitz [off-list ref]
Subject: [PATCH 3/5] net: cadence: macb: implement EEE TX LPI
support
Implement Energy Efficient Ethernet TX Low Power Idle using phylink's
managed EEE framework. The Cadence GEM MAC has no built-in idle timer
— TXLPIEN (NCR bit 19) immediately blocks all TX when set and the MAC does
NOT auto-wake — so the driver
Implement Energy Efficient Ethernet TX Low Power Idle using phylink's
managed EEE framework. The Cadence GEM MAC has no built-in idle timer
— TXLPIEN (NCR bit 19) immediately blocks all TX when set and the MAC does
NOT auto-wake — so the driver uses a software delayed_work timer for idle
detection.
The TX LPI lifecycle:
- phylink calls mac_enable_tx_lpi() after link-up with the negotiated
timer value. The driver defers the first LPI entry by 1 second per
IEEE 802.3az section 22.7a.
- macb_tx_complete() reschedules the idle timer after each TX drain.
- macb_start_xmit() wakes from LPI by clearing TXLPIEN, cancelling
the pending work, and waiting 50us (conservative Tw_sys) before
initiating the transmit.
- phylink calls mac_disable_tx_lpi() before link-down, which cancels
the work and clears TXLPIEN.
The phylink_config is populated with LPI capabilities (MII, GMII, RGMII
modes; 100FD and 1000FD speeds) and a 250ms default idle timer, gated on
MACB_CAPS_EEE.
Signed-off-by: Nicolai Buchwitz <redacted>
---
drivers/net/ethernet/cadence/macb.h | 5 +
drivers/net/ethernet/cadence/macb_main.c | 111
+++++++++++++++++++++++
2 files changed, 116 insertions(+)
diff --git a/drivers/net/ethernet/cadence/macb.h
b/drivers/net/ethernet/cadence/macb.h
index e3520e5aec67..c69828b27dae 100644
+
+static void macb_tx_lpi_schedule(struct macb *bp) {
+ if (bp->eee_active)
+ mod_delayed_work(system_wq, &bp->tx_lpi_work,
+ usecs_to_jiffies(bp->tx_lpi_timer));
+}
+
+/* Wake from LPI before transmitting. The MAC must deassert TXLPIEN
+ * and wait for the PHY to exit LPI before any frame can be sent.
+ * IEEE 802.3az Tw_sys is ~17us for 1000BASE-T, ~30us for 100BASE-TX;
+ * we use a conservative 50us.
+ */
+static void macb_tx_lpi_wake(struct macb *bp) {
+ if (!macb_tx_lpi_set(bp, false))
+ return;
+
+ cancel_delayed_work(&bp->tx_lpi_work);
+ udelay(50);
Any reason the 50µs busy-wait in xmit path? Can it be avoided?
The 50us delay is required by IEEE 802.3az. After clearing TXLPIEN the
PHY needs time to exit LPI and re-establish normal operation before the
MAC can transmit. This is defined as Tw_sys_tx - approximately 16.5us
for 1000BASE-T and 30us for 100BASE-TX. We use a conservative 50us to
cover both speeds without needing to track the current link rate.
Testing without the delay confirmed packet loss on the first frame after
waking from LPI, as the PHY had not yet fully transitioned back to
normal mode.
This delay is specific to the GEM MAC because TXLPIEN directly and
immediately controls LPI with no hardware enforcement of Tw_sys_tx - the
software must enforce it. Other phylink-managed EEE drivers (mvneta,
stmmac, lan743x, mtk) don't need an explicit delay because their
hardware handles the wake timing automatically.
The cost is also bounded: the delay only fires when TXLPIEN was
actually asserted, i.e. on the first transmit after an idle period.
[...]
Nicolai
On Wed Feb 25, 2026 at 10:15 AM CET, Nicolai Buchwitz wrote:
quoted hunk
Implement Energy Efficient Ethernet TX Low Power Idle using phylink's
managed EEE framework. The Cadence GEM MAC has no built-in idle timer
— TXLPIEN (NCR bit 19) immediately blocks all TX when set and the MAC
does NOT auto-wake — so the driver uses a software delayed_work timer
for idle detection.
The TX LPI lifecycle:
- phylink calls mac_enable_tx_lpi() after link-up with the negotiated
timer value. The driver defers the first LPI entry by 1 second per
IEEE 802.3az section 22.7a.
- macb_tx_complete() reschedules the idle timer after each TX drain.
- macb_start_xmit() wakes from LPI by clearing TXLPIEN, cancelling
the pending work, and waiting 50us (conservative Tw_sys) before
initiating the transmit.
- phylink calls mac_disable_tx_lpi() before link-down, which cancels
the work and clears TXLPIEN.
The phylink_config is populated with LPI capabilities (MII, GMII, RGMII
modes; 100FD and 1000FD speeds) and a 250ms default idle timer, gated
on MACB_CAPS_EEE.
Signed-off-by: Nicolai Buchwitz <redacted>
---
drivers/net/ethernet/cadence/macb.h | 5 +
drivers/net/ethernet/cadence/macb_main.c | 111 +++++++++++++++++++++++
2 files changed, 116 insertions(+)
+/* Wake from LPI before transmitting. The MAC must deassert TXLPIEN
+ * and wait for the PHY to exit LPI before any frame can be sent.
+ * IEEE 802.3az Tw_sys is ~17us for 1000BASE-T, ~30us for 100BASE-TX;
+ * we use a conservative 50us.
+ */
+static void macb_tx_lpi_wake(struct macb *bp)
+{
+ if (!macb_tx_lpi_set(bp, false))
+ return;
+
+ cancel_delayed_work(&bp->tx_lpi_work);
+ udelay(50);
+}
Should this be protected by a bp->eee_active condition? It could go
in macb_tx_lpi_wake(). We avoid a spinlock acquire per xmit for most
platforms. Probably negligeable though.
For the full series:
Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com>
Thanks!
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Should this be protected by a bp->eee_active condition? It could go
in macb_tx_lpi_wake(). We avoid a spinlock acquire per xmit for most
platforms. Probably negligeable though.
It will read the register, find the bit clear, and then return if
EEE is already disabled.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Should this be protected by a bp->eee_active condition? It could go
in macb_tx_lpi_wake(). We avoid a spinlock acquire per xmit for most
platforms. Probably negligeable though.
It will read the register, find the bit clear, and then return if
EEE is already disabled.
Yes I agree with your sentence, sorry my point was unclear. I was not
describing a bug but rather a performance optimisation.
We would look up bp->eee_active to know if we can avoid calling
macb_tx_lpi_set(), to avoid grabbing bp->lock once per xmit.
That spinlock is interface-wide.
Thanks,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Should this be protected by a bp->eee_active condition? It could go
in macb_tx_lpi_wake(). We avoid a spinlock acquire per xmit for most
platforms. Probably negligeable though.
It will read the register, find the bit clear, and then return if
EEE is already disabled.
Yes I agree with your sentence, sorry my point was unclear. I was not
describing a bug but rather a performance optimisation.
We would look up bp->eee_active to know if we can avoid calling
macb_tx_lpi_set(), to avoid grabbing bp->lock once per xmit.
That spinlock is interface-wide.
Should this be protected by a bp->eee_active condition? It could go
in macb_tx_lpi_wake(). We avoid a spinlock acquire per xmit for most
platforms. Probably negligeable though.
It will read the register, find the bit clear, and then return if
EEE is already disabled.
Yes I agree with your sentence, sorry my point was unclear. I was not
describing a bug but rather a performance optimisation.
We would look up bp->eee_active to know if we can avoid calling
macb_tx_lpi_set(), to avoid grabbing bp->lock once per xmit.
That spinlock is interface-wide.
I discovered this series at its V3.
It seems like I was suggesting a mix of both V2 & V3 approaches.
// V2 was:
static void macb_tx_lpi_wake(struct macb *bp)
{
if (!bp->eee_active)
return;
macb_tx_lpi_set(bp, false);
cancel_delayed_work(&bp->tx_lpi_work);
udelay(50);
}
// V3 & V3 are:
static void macb_tx_lpi_wake(struct macb *bp)
{
if (!macb_tx_lpi_set(bp, false))
return;
cancel_delayed_work(&bp->tx_lpi_work);
udelay(50);
}
// I was suggesting:
static void macb_tx_lpi_wake(struct macb *bp)
{
if (!eee_active || !macb_tx_lpi_set(bp, false))
return;
cancel_delayed_work(&bp->tx_lpi_work);
udelay(50);
}
But talking about perf, let's measure.
I don't get any measurable performance improvement on average/max time
spent in macb_start_xmit() between net-next and this series. We spend
<3µs per call anyway. 10s iperf3 1G TCP test on EyeQ5, ftrace function
graph tracer on macb_start_xmit().
Summary: you can ignore my remark.
Thanks,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Should this be protected by a bp->eee_active condition? It could go
in macb_tx_lpi_wake(). We avoid a spinlock acquire per xmit for
most
platforms. Probably negligeable though.
It will read the register, find the bit clear, and then return if
EEE is already disabled.
Yes I agree with your sentence, sorry my point was unclear. I was not
describing a bug but rather a performance optimisation.
We would look up bp->eee_active to know if we can avoid calling
macb_tx_lpi_set(), to avoid grabbing bp->lock once per xmit.
That spinlock is interface-wide.
I discovered this series at its V3.
It seems like I was suggesting a mix of both V2 & V3 approaches.
// V2 was:
static void macb_tx_lpi_wake(struct macb *bp)
{
if (!bp->eee_active)
return;
macb_tx_lpi_set(bp, false);
cancel_delayed_work(&bp->tx_lpi_work);
udelay(50);
}
// V3 & V3 are:
static void macb_tx_lpi_wake(struct macb *bp)
{
if (!macb_tx_lpi_set(bp, false))
return;
cancel_delayed_work(&bp->tx_lpi_work);
udelay(50);
}
// I was suggesting:
static void macb_tx_lpi_wake(struct macb *bp)
{
if (!eee_active || !macb_tx_lpi_set(bp, false))
return;
cancel_delayed_work(&bp->tx_lpi_work);
udelay(50);
}
But talking about perf, let's measure.
Tthanks for testing! Since you have the hardware at hand, would you be
willing to add MACB_CAPS_EEE to eyeq5_config as well? I'm happy to
include it in the series if you can confirm it works correctly.
I don't get any measurable performance improvement on average/max time
spent in macb_start_xmit() between net-next and this series. We spend
<3µs per call anyway. 10s iperf3 1G TCP test on EyeQ5, ftrace function
graph tracer on macb_start_xmit().
Summary: you can ignore my remark.
Thanks,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Hello Nicolai,
On Fri Feb 27, 2026 at 10:00 AM CET, Nicolai Buchwitz wrote:
On 26.2.2026 14:50, Théo Lebrun wrote:
quoted
On Thu Feb 26, 2026 at 11:49 AM CET, Nicolai Buchwitz wrote:
But talking about perf, let's measure.
Tthanks for testing! Since you have the hardware at hand, would you be
willing to add MACB_CAPS_EEE to eyeq5_config as well? I'm happy to
include it in the series if you can confirm it works correctly.
Tested-by: Théo Lebrun <theo.lebrun@bootlin.com>
Tested using a hardware loopback and a net namespace.
# ip netns add netns_eth1
# ip link set eth1 netns netns_eth1
# ip -n netns_eth1 a add 10.0.0.2/24 dev eth1
# ip -n netns_eth1 link set eth1 up
# ip a add 10.0.0.1/24 dev eth0
# ip link set eth0 up
... ping and iperf3 ...
# ethtool --show-eee eth0
EEE settings for eth0:
enabled - active
250000 (us)
Supported EEE link modes: 100baseT/Full
1000baseT/Full
Advertised EEE link modes: 100baseT/Full
1000baseT/Full
Link partner advertised EEE link modes: 100baseT/Full
1000baseT/Full
# ip netns exec netns_eth1 ethtool --show-eee eth1
EEE settings for eth1:
enabled - active
250000 (us)
Supported EEE link modes: 100baseT/Full
1000baseT/Full
Advertised EEE link modes: 100baseT/Full
1000baseT/Full
Link partner advertised EEE link modes: 100baseT/Full
1000baseT/Full
Thanks,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Add register and bitfield definitions for the Cadence GEM MAC's
IEEE 802.3az Energy Efficient Ethernet (EEE) support:
- LPI statistics counter registers (GEM_RXLPI, GEM_RXLPITIME,
GEM_TXLPI, GEM_TXLPITIME) at offsets 0x270-0x27c
- TX LPI enable bitfield (GEM_TXLPIEN) in the NCR register (bit 19),
which directly asserts/deasserts LPI on the transmit path
- MACB_CAPS_EEE capability flag to gate EEE support per platform
These registers are present in all Cadence GEM revisions that support
EEE (verified on SAMA5D2, SAME70, PIC32CZ, and RP1 variants).
No functional change.
Signed-off-by: Nicolai Buchwitz <redacted>
---
drivers/net/ethernet/cadence/macb.h | 7 +++++++
1 file changed, 7 insertions(+)
Hello Nicolai,
On Wed Feb 25, 2026 at 10:15 AM CET, Nicolai Buchwitz wrote:
Add register and bitfield definitions for the Cadence GEM MAC's
IEEE 802.3az Energy Efficient Ethernet (EEE) support:
nit: could this patch be squashed into [3/5]?
- LPI statistics counter registers (GEM_RXLPI, GEM_RXLPITIME,
GEM_TXLPI, GEM_TXLPITIME) at offsets 0x270-0x27c
- TX LPI enable bitfield (GEM_TXLPIEN) in the NCR register (bit 19),
which directly asserts/deasserts LPI on the transmit path
- MACB_CAPS_EEE capability flag to gate EEE support per platform
These registers are present in all Cadence GEM revisions that support
EEE (verified on SAMA5D2, SAME70, PIC32CZ, and RP1 variants).
Would the capability flag deserve to be added to any other compatible?
Thanks,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Implement ethtool get_eee and set_eee operations for the Cadence GEM
MAC, delegating to phylink for PHY-level EEE negotiation state.
The MAC-level LPI control (TXLPIEN) is not manipulated directly in the
ethtool ops - phylink manages the full EEE lifecycle through the
mac_enable_tx_lpi / mac_disable_tx_lpi callbacks.
Both ops are gated on MACB_CAPS_EEE; platforms without the capability
flag return -EOPNOTSUPP.
Signed-off-by: Nicolai Buchwitz <redacted>
---
drivers/net/ethernet/cadence/macb_main.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
Enable IEEE 802.3az Energy Efficient Ethernet on the Raspberry Pi 5's
RP1 southbridge by adding MACB_CAPS_EEE to its platform config.
The RP1 contains a Cadence GEM_GXL MAC (revision 0x00070109) paired
with a Broadcom BCM54213PE PHY, both of which support EEE at
1000BASE-T and 100BASE-TX.
Signed-off-by: Nicolai Buchwitz <redacted>
---
drivers/net/ethernet/cadence/macb_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Add Energy Efficient Ethernet (IEEE 802.3az) support to the Cadence GEM
(macb) driver using phylink's managed EEE framework. The GEM MAC has
hardware LPI registers but no built-in idle timer, so the driver
implements software-managed TX LPI using a delayed_work timer while
delegating EEE negotiation and ethtool state to phylink.
Changes from v2:
- macb_tx_lpi_set() now returns bool indicating whether the register
value actually changed, avoiding redundant writes.
- Removed tx_lpi_enabled field from struct macb; LPI state is tracked
entirely within the spinlock-protected register read/modify/write.
- macb_tx_lpi_wake() uses the return value of macb_tx_lpi_set() to
skip the cancel/udelay when TXLPIEN was already clear.
All changes based on feedback from Russell King.
Apologies for the missing subject prefix and version tags on this
series - should have been [PATCH net-next v3]. I'm still fairly new
to the kernel mailing list workflow and building up the muscle memory
around git-format-patch/send-email. I'll resend as v4 with the proper
tags. In the meantime, feedback on the code itself is very welcome.
Changes from v1:
- Rewrote to use phylink managed EEE (mac_enable_tx_lpi /
mac_disable_tx_lpi callbacks) instead of the obsolete
phy_init_eee() approach, as recommended by Russell King.
- ethtool get_eee/set_eee are now pure phylink passthroughs.
- Removed all manual EEE state tracking from mac_link_up/down;
phylink handles the lifecycle.
The series is structured as follows:
1. Register definitions: LPI counter offsets (0x270-0x27c), TXLPIEN
bitfield (NCR bit 19), and MACB_CAPS_EEE capability flag.
2. LPI statistics: Expose the four hardware EEE counters (RX/TX LPI
transitions and time) through ethtool -S, accumulated in software
since they are clear-on-read.
3. TX LPI engine: phylink mac_enable_tx_lpi / mac_disable_tx_lpi
callbacks with a delayed_work-based idle timer. LPI entry is
deferred 1 second after link-up per IEEE 802.3az. Wake before
transmit with a conservative 50us PHY wake delay.
4. ethtool EEE ops: get_eee/set_eee delegating to phylink for PHY
negotiation and timer management.
5. RP1 enablement: Set MACB_CAPS_EEE for the Raspberry Pi 5's RP1
southbridge (Cadence GEM_GXL rev 0x00070109 + BCM54213PE PHY).
Tested on Raspberry Pi 5 (1000BASE-T, BCM54213PE PHY, 250ms LPI timer):
iperf3 throughput (no regression):
TCP TX: 937.8 Mbit/s (EEE on) vs 937.0 Mbit/s (EEE off)
TCP RX: 936.5 Mbit/s both
Latency (ping RTT, small expected increase from LPI wake):
1s interval: 0.273 ms (EEE on) vs 0.181 ms (EEE off)
10ms interval: 0.206 ms (EEE on) vs 0.168 ms (EEE off)
flood ping: 0.200 ms (EEE on) vs 0.156 ms (EEE off)
LPI counters (ethtool -S, 1s-interval ping, EEE on):
tx_lpi_transitions: 112
tx_lpi_time: 15574651
Zero packet loss across all tests. Also verified with
ethtool --show-eee / --set-eee and cable unplug/replug cycling.
Nicolai Buchwitz (5):
net: cadence: macb: add EEE register definitions and capability flag
net: cadence: macb: add EEE LPI statistics counters
net: cadence: macb: implement EEE TX LPI support
net: cadence: macb: add ethtool EEE support
net: cadence: macb: enable EEE for Raspberry Pi RP1
drivers/net/ethernet/cadence/macb.h | 20 ++++
drivers/net/ethernet/cadence/macb_main.c | 136 ++++++++++++++++++++++-
2 files changed, 155 insertions(+), 1 deletion(-)