On 2/6/2024 5:29 AM, Vladimir Oltean wrote:
On Tue, Feb 06, 2024 at 01:12:33PM +0000, Russell King (Oracle) wrote:
quoted
quoted
I know next to nothing about EEE and especially the implementation on
Broadcom switches. But is the information brought by B53_EEE_LPI_INDICATE
completely redundant? Is it actually in the system's best interest to
ignore it?
That's a review comment that should have been made when the original
change to phylib was done, because it's already ignored in kernels
today since the commit changing phylib that I've referenced in this
series - since e->eee_enabled and e->eee_active will be overwritten by
phylib.
That's fair, but commit d1420bb99515 ("net: phy: improve generic EEE
ethtool functions") is dated November 2018, and my involvement with the
kernel started in March 2019. So it would have been a bit difficult for
me to make this observation back then.
quoted
If we need B53_EEE_LPI_INDICATE to do something, then we need to have
a discussion about it, and decide how that fits in with the EEE
interface, and how to work around phylib's implementation.
Hopefully Florian or Doug can quickly clarify whether this is the case
or not.
Russell's replacement is actually a better one because it will return a
stable state. B53_EEE_LPI_INDICATE would indicate when the switch port's
built-in PHY asserts the LPI signal to its MAC, which could be transient
AFAICT.
--
Florian