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]

Date: Sat, 6 Jan 2024 13:41:01 +0100
From: Ezra Buehler <ezra@...yb.ch>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
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 2, 2024 at 7:58 PM Russell King (Oracle)
<linux@...linux.org.uk> wrote:
>
> 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?

When profiling with ftrace, I see that executing macb_mdio_read_c45()
takes about 20ms. The function calls macb_mdio_wait_for_idle() 3 times,
where the latter 2 invocations take about 10ms each. The
macb_mdio_wait_for_idle() function invokes the read_poll_timeout() macro
with a timeout of 1 second, which we obviously do not hit.

To me it looks like we are simply waiting for the hardware to perform
the transaction, i.e. write out the address and read the register (which
is read as 0xFFFF).

I've checked the MDIO clock, it is at 2MHz.

So, any suggestions for what to look into next?