netdev - Re: [PATCH RFC net-next] net: phy: micrel: Improve loopback support if autoneg is enabled

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: <Zw0jHKKt6z4O3D5U@shell.armlinux.org.uk>
Date: Mon, 14 Oct 2024 14:56:44 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>
Cc: Gerhard Engleder <gerhard@...leder-embedded.com>, hkallweit1@...il.com,
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com, netdev@...r.kernel.org
Subject: Re: [PATCH RFC net-next] net: phy: micrel: Improve loopback support
 if autoneg is enabled

On Mon, Oct 14, 2024 at 03:18:29PM +0200, Andrew Lunn wrote:
> Russell's reading of 802.3 is that 1G requires autoneg. Hence the
> change. Loopback is however special. Either the PHY needs to do
> autoneg with itself, which is pretty unlikely, or it needs to ignore
> autoneg and loopback packets independent of the autoneg status.
> 
> What does 802.3 say about loopback? At least the bit in BMCR must be
> defined. Is there more? Any mention of how it should work in
> combination with autoneg?

Loopback is not defined to a great degree in 802.3, its only suggesting
that as much of the PHY data path should be exercised as possible.
However, it does state in clause 22 that the duplex bit should not
affect loopback.

It doesn't make any reference to speed or autoneg.

Given that PHYs that support multiple speeds need to have different
data paths through them, and the requirement for loopback to use as
much of the data path as possible, it does seem sensible that some
PHYs may not be able to negotiate with themselves in loopback mode,
(e.g. at 1G speeds, one PHY needs to be master the other slave, how
does a single PHY become both master and slave at the same time...)
then maybe forced speed is necessary when entering loopback.

So probably yes, when entering loopback, we probably ought to force
the PHY speed, but that gets difficult for a PHY that is down and
as autoneg enabled (what speed do we force?)

We do have the forced-settings in phy->autoneg, phy->speed and
phy->duplex even after the referred to commit, so we could use
that to switch the PHY back to a forced mode. However, I suepct
we're into PHY specific waters here - whether the PHY supports
1G without AN even in loopback mode is probably implementation
specific.

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