Thread (49 messages) 49 messages, 4 authors, 2023-05-31

Re: [RFC/RFTv3 00/24] net: ethernet: Rework EEE

From: Andrew Lunn <andrew@lunn.ch>
Date: 2023-05-30 19:48:21

On Tue, May 30, 2023 at 11:31:04AM -0700, Florian Fainelli wrote:
Hi Andrew, Russell,

On 3/30/23 17:54, Andrew Lunn wrote:
quoted
Most MAC drivers get EEE wrong. The API to the PHY is not very
obvious, which is probably why. Rework the API, pushing most of the
EEE handling into phylib core, leaving the MAC drivers to just
enable/disable support for EEE in there change_link call back, or
phylink mac_link_up callback.

MAC drivers are now expect to indicate to phylib/phylink if they
support EEE. If not, no EEE link modes are advertised. If the MAC does
support EEE, on phy_start()/phylink_start() EEE advertisement is
configured.
Thanks for doing this work, because it really is a happy mess out there. A
few questions as I have been using mvneta as the reference for fixing GENET
and its shortcomings.

In your new patches the decision to enable EEE is purely based upon the
eee_active boolean and not eee_enabled && tx_lpi_enabled unlike what mvneta
useed to do.
I don't really care much what we decide means 'enabled'. I just want
it moved out of MAC drivers and into the core so it is consistent.

Russel, if you want to propose something which works for both Copper
and Fibre, i'm happy to implement it. But as you pointed out, we need
to decide where. Maybe phylib handles copper, and phylink is layered
on top and handles fibre?

	  Andrew
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help