Message-ID: <20230531104346.2a131c42@wsk>
Date:   Wed, 31 May 2023 10:43:46 +0200
From:   Lukasz Majewski <lukma@...x.de>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC] net: dsa: slave: Advertise correct EEE capabilities at
 slave PHY setup

Hi Russell,

> On Tue, May 30, 2023 at 04:47:31PM +0200, Lukasz Majewski wrote:
> > Hi Andrew,
> >   
> > > > 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.  
> > 
> > It is mv88e6071.
> >   
> > > I've not looked in too much detail,
> > > but i think different switch families have different EEE
> > > capabilities.  
> > 
> > Yes, some (like b53) have the ability to disable EEE in the HW.
> > 
> > The above one from Marvell seems to have EEE always enabled (in
> > silicon) and the only possibility is to not advertise it [*].  
> 
> Right, and that tells the remote end "we don't support EEE" so the
> remote end should then disable EEE support.
> 
> Meanwhile the local MAC will _still_ signal LPI towards its PHY. I
> have no idea whether the PHY will pass that LPI signal onwards to
> the media in that case, or if it prevents entering low power mode.
> 
> It would be interesting to connect two of these switches together,
> put a 'scope on the signals between the PHY and the media isolation
> transformer, and see whether it's entering low power mode,
> comparing when EEE is successfully negotiated vs not negotiated.
> 
> My suspicion would be that in the case where the MAC always signals
> LPI to the PHY, the result of negotiation won't make a blind bit of
> difference.
> 
> > > But in general, as Russell pointed out, there is no MAC support
> > > for EEE in the mv88e6xxx driver.  
> > 
> > I may be wrong, but aren't we accessing this switch PHYs via c45 ?
> > (MDIO_MMD_PCS devices and e.g. MDIO_PCS_EEE_ABLE registers)?  
> 
> As I've said - EEE is a MAC-to-MAC thing. The PHYs do the capability
> negotiation and handle the media dependent part of EEE. However, it's
> the MACs that signal to the PHY "I'm idle, please enter low power
> mode" and when both ends that they're idle, the media link only then
> drops into low power mode. This is the basic high-level operation of
> EEE in an 802.3 compliant system.
> 
> As I've also said, there are PHYs out there which do their own thing
> as an "enhancement" to allow MACs that aren't EEE capable to gain
> *some* of the power savings from EEE (and I previously noted one
> such example.)
> 
> The PHY EEE configuration is always done via Clause 45 - either
> through proper clause 45 cycles on the MDIO bus, or through the MMD
> access through a couple of clause 22 registers. There aren't the
> registers in the clause 22 address space for EEE.
> 
> The MDIO_PCS_EEE_ABLE registers describe what the capabilities of the
> PHY is to the management software (in this case phylib). These are not
> supposed to change. The advertisements are programmed via the
> autonegotiation MMD register set. There's some additional
> configuration bits in the PHY which control whether the clock to the
> MAC is stopped when entering EEE low-power mode.
> 
> However, even with all that, the MAC is still what is involved in
> giving the PHY permission to enter EEE low-power mode.
> 
> The broad outline sequence in an 802.3 compliant setup is:
> 
> - Whenever the MAC sends a packet, it resets the LPI timer.
> - When LPI timer expires, MAC signals to PHY that it can enter
>   low-power mode.
> - When the PHY at both ends both agree that they have permission from
>   their respective MACs to enter low power mode, they initiate the
>   process to put the media into low power mode.
> - If the PHY has been given permission from management software to
> stop clock, the PHY will stop the clock to the MAC.
> - When the MAC has a packet to send, the MAC stops signalling
> low-power mode to the PHY.
> - The PHY restores the clock if it was stopped, and wakes up the link,
>   thereby causing the remote PHY to also wake up.
> - Normal operation resumes.
> 
> 802.3 EEE is not a PHY-to-PHY thing, it's MAC-to-MAC.
> 

Thanks for the detailed explanation.

With "switch" setup - where I do have MAC from imx8 (fec driver)
connected to e.g. mv88e6071 with "fixed-link", I do guess that the EEE
management is done solely in mv88e6071?

In other words - the mv88e6071 solely decides if its internal PHY shall
signal EEE to the peer switch.

Just for the record - the mv88e6071 has a "register space" where one
can tune assertion and wakeup timers. Unfortunately, there is no "bit"
setting to disable EEE in the HW.


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@...x.de

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists