netdev - Re: [PATCH net-next] bnxt: convert EEE handling to use linkmode bitmaps

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: <Zb939rzMQchueX2r@shell.armlinux.org.uk>
Date: Sun, 4 Feb 2024 11:41:42 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Michael Chan <michael.chan@...adcom.com>
Cc: Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>,
	Jakub Kicinski <kuba@...nel.org>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] bnxt: convert EEE handling to use linkmode
 bitmaps

On Sat, Feb 03, 2024 at 04:16:51PM -0800, Michael Chan wrote:
> On Sat, Feb 3, 2024 at 1:59 PM Andrew Lunn <andrew@...n.ch> wrote:
> >
> > > -     if (!edata->advertised_u32) {
> > > -             edata->advertised_u32 = advertising & eee->supported_u32;
> > > -     } else if (edata->advertised_u32 & ~advertising) {
> > > -             netdev_warn(dev, "EEE advertised %x must be a subset of autoneg advertised speeds %x\n",
> > > -                         edata->advertised_u32, advertising);
> >
> > That warning text looks wrong. I think it should be
> >
> > EEE advertised %x must be a subset of autoneg supported speeds %x
> >
> > and it should print eee->supported, not advertising.
> >
> I think it is correct.  EEE advertised must be a subset of the
> advertised speed.

Where is that a requirement?

If a PHY supports e.g. 1G, 100M, and supports EEE at those two speeds,
but is only advertising 1G, then the only speed that could be
negotiated is 1G.

The EEE negotiation will also occur, and if the link partner also
advertises EEE at 1G and 100M, the result of that negotiation is that
EEE _can_ _be_ _used_ at 1G and 100M speeds.

However, the PHY has negotiated 1G speed, so it now checks to see
whether the EEE negotiation included 1G speed. The fact that the EEE
negotiation also includes 100M is irrelevant - the negotiated speed
is 1G, and that's all that determines whether EEE will be used for
the negotiated link speed.

The exception is if the PHY is buggy and doesn't follow this, e.g.
assuming that if any EEE speed was negotiated that EEE is supported,
but that would be a recipe for disaster given that a link partner
may only advertise EEE at 100M, we may be advertising 100M and 1G
(both for EEE and link) so we end up using 1G with EEE despite the
link partner not supporting it.

So, whatever way I look at it, the statement "the EEE advertisement
must be a subset of the link advertisement" makes absolutely no sense
to me, and is probably wrong.

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