netdev - Re: [PATCH net] net: mdio: Prevent Clause 45 scan on SMSC PHYs

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: <ZZRct1o21NIKbYX1@shell.armlinux.org.uk>
Date: Tue, 2 Jan 2024 18:57:59 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Ezra Buehler <ezra@...yb.ch>
Cc: Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>,
	Tristram Ha <Tristram.Ha@...rochip.com>,
	Michael Walle <michael@...le.cc>,
	Jesse Brandeburg <jesse.brandeburg@...el.com>,
	netdev@...r.kernel.org
Subject: Re: [PATCH net] net: mdio: Prevent Clause 45 scan on SMSC PHYs

On Tue, Jan 02, 2024 at 07:08:32PM +0100, Ezra Buehler wrote:
> Hi Andrew,
> 
> On Tue, Jan 2, 2024 at 4:50 PM Andrew Lunn <andrew@...n.ch> wrote:
> >
> > I do however disagree with this statement in the original patch:
> >
> > > AFAICT all SMSC/Microchip PHYs are Clause 22 devices.
> 
> Excuse my ignorance, I am by no means an expert here. I guess what I
> wanted to say was:
> 
> By skimming over some datasheets for similar SMSC/Microchip PHYs, I
> could not find any evidence that they support Clause 45 scanning
> (other than not responding).
> 
> > drivers/net/phy/smsc.c has a number of phy_write_mmd()/phy_read_mmd()
> > in it. But that device has a different OUI.
> 
> I guess I am confused here, AFAICT all PHYs in smsc.c have the same OUI
> (phy_id >> 10).
> 
> > However, the commit message says:
> >
> > > Running a Clause 45 scan on an SMSC/Microchip LAN8720A PHY will (at
> > > least with our setup) considerably slow down kernel startup and
> > > ultimately result in a board reset.
> >
> > So we need to clarify the real issue here. Does the C45 scan work
> > correctly, but the board watchdog timer is too short and fires? We
> > should not be extended this workaround when its a bad watchdog
> > configuration issue...
> 
> Changing the watchdog configuration is not an option here. We are
> talking about a slowdown of several seconds here, that is not acceptable
> on its own.

Any ideas why the scan is taking so long?

For each PHY address (of which there are 32) we scan each MMD between
1 and 31 inclusive. We attempt to read the devices-in-package
registers. That means 32 * 32 * 2 calls to the mdiobus_c45_read(),
which is 2048 calls. Each is two MDIO transactions on the bus, so
that's 4096. Each is 64 bits long including preamble, and at 2.5MHz
(the "old" maximum) it should take about 100ms to scan the each
MMD on each PHY address to determine whether a device is present.

I'm guessing the MDIO driver you are using is probably using a software
timeout which is extending the latency of each bus frame considerably.
Maybe that is where one should be looking if the timing is not
acceptable?

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