Re: [RFC] net: dsa: slave: Advertise correct EEE capabilities at slave PHY setup

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Tue, May 30, 2023 at 04:26:49PM +0200, Andrew Lunn wrote:
> > So, I'm wondering what's actually going on here... can you give
> > any more details about the hardware setup?
> 
> And what switch it actually is. I've not looked in too much detail,
> but i think different switch families have different EEE capabilities.
> But in general, as Russell pointed out, there is no MAC support for
> EEE in the mv88e6xxx driver.

... except for the built-in PHYs, which if they successfully negotiate
EEE, that status is communicated back to the MAC in that one sees
MV88E6352_PORT_STS_EEE set, which results in the MAC being able to
signal LPI to the PHY... and I've stuck a 'scope on the PHY media-side
signals in the past and have seen that activity does stop without there
needing to be any help from the driver for this.

At least reading the information I have for the 88E6352, there is no
configuration of LPI timers, nor any seperate LPI enable. If EEE is
enabled at the MAC, then LPI will be signalled according to whatever
Marvell decided would be appropriate.

For an external PHY that the PPU is not polling, the only way that
we'd have EEE functional is if we forced EEE in port control register 1
on switches that support those bits. In other words setting both the
EEE and FORCE_EEE bits...

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