Open
Conversation
This reverts commit 85b196f.
Wire phy_ethtool_nway_reset() as the .nway_reset ethtool operation, allowing userspace to restart PHY autonegotiation via 'ethtool -r'. Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
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 - RX LPI status bit change interrupt bitfield (GEM_RXLPISBC) in the ISR/IER/IDR/IMR registers (bit 27) - 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 <nb@tipi-net.de>
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 <nb@tipi-net.de>
Implement software-managed TX Low Power Idle (LPI) for the Cadence GEM MAC as part of IEEE 802.3az Energy Efficient Ethernet support. The GEM MAC has no built-in idle timer — the TXLPIEN bit (NCR bit 19) immediately asserts LPI and blocks all TX while set. The MAC does not auto-wake for transmit. Per Microchip GMAC documentation (section 40.6.19): "It is best to use firmware to control LPI." This patch implements a software idle timer using delayed_work: - On TX completion with an empty ring, schedule LPI entry after a configurable idle timeout (default 5ms) - On TX start, wake from LPI by clearing TXLPIEN, cancelling any pending re-entry, and waiting 50us for the PHY to exit LPI (conservative vs IEEE 802.3az Tw_sys of ~17us/~30us) - On link up, check EEE negotiation via phy_init_eee() and defer first LPI entry by 1 second per IEEE 802.3az requirements - On link down, immediately cancel pending work and clear TXLPIEN The implementation is gated on MACB_CAPS_EEE so platforms must explicitly opt in via their macb_config. Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
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. Instead, phylink_ethtool_set_eee() updates the PHY's EEE advertisement, which triggers link renegotiation. The mac_link_up callback then checks the negotiated EEE state and enables LPI accordingly. Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
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 <nb@tipi-net.de>
Contributor
Author
|
f0d41dc is not directly EEE related, but I noticed it was missing while debugging |
Contributor
|
Thanks, Nicolai - this looks great. For anyone wishing to try the new EEE capability, you can install a trial build using |
Contributor
|
For comparison, these are the values I get after being up for a few minutes: |
Contributor
Author
|
For better comparison: is the ethernet link actively used or not? If yes, how do the tx lpi rate change when the ethernet is mostly idle (eg wifi used)? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This adds EEE support to the macb driver for the Pi 5 / CM5. Right now EEE is broken on the Pi because the PHY advertises EEE but the MAC has no LPI support, so it was marked as broken in #6900. This series fixes that by implementing proper software-managed TX LPI in the driver and reverting the DT workaround.
See #6855
This should go through mainline as the EEE registers are the same across all Cadence GEM variants (SAMA5D2, SAME70, PIC32CZ, RP1, ...) and the code is generic, just gated on a capability flag. I'm looking for early feedback from Pi users before sending it upstream though. If you've got a Pi 5 or CM5, give it a spin and let me know how it goes — link stability,
ethtool --show-eee,ethtool -S | grep lpi, that kind of thing.