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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZHYRgIb6UCYq1n/Z@shell.armlinux.org.uk>
Date: Tue, 30 May 2023 16:08:48 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Lukasz Majewski <lukma@...x.de>
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

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.

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