netdev - Re: [RFC] mdio demux multiplexer driver

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: <aKNS9uPpyeQgWrBY@shell.armlinux.org.uk>
Date: Mon, 18 Aug 2025 17:21:10 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Jisheng Zhang <jszhang@...nel.org>
Cc: Andrew Lunn <andrew@...n.ch>,
	Florian Fainelli <florian.fainelli@...adcom.com>,
	Jakub Kicinski <kuba@...nel.org>,
	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [RFC] mdio demux multiplexer driver

On Mon, Aug 18, 2025 at 11:39:35PM +0800, Jisheng Zhang wrote:
> stmmac :(  And the MMIO reg doesn't sit together with MAC IP's.
> As can be seen, the stmmac mdio registers sit in the middle of the
> MAC regs. And current stmmac still tries to register a mdio driver for
> the MDIO bus master. And to be honest, it's not the stmmac make things
> messy, but the two MDIO masters sharing the single clk and data lines
> makes the mess. Modeling the mmio as a demux seems a just so so but
> not perfect solution.

So, let's say we have four devices, stmmac0, stmmac1, stmmac2 and
stmmac3. We decide that we will access the PHYs via stmmac0.

In DT, we describe the four PHYs under stmmac0's node, with labels
for each. We then reference the lables using phy-handle in each
of the stmmac device nodes.

One of the issues with stmmac is that the driver will successfully
probe without the PHYs being present, because the driver only looks
for PHYs when the netdev is adminsitratively brought up. The problem
here is that there is no "EPROBE_DEFER" mechanism available in this
path. Returning any error code goes straight back to e.g. userspace
and it's up to userspace to decide what to do.

Commands like "ip link" will just report the error and fail.

I don't know how programs like systemd's mega-suite of programs deal
would with any errors - would they retry or declare the interface to
have failed.

While I can see the advantage of a demux driver, this problem remains
whether we have a demux or not, unless somehow the probe of stmmac is
influenced by the presence or not of the demux driver.

Remember of course that the demux driver has to cope with locking to
ensure two transactions can't happen at the same time (it needs a
common lock somehow shared between each user).

If we can't solve these, then one might as well go with all PHYs on
one MDIO bus and keep it relatively simple.

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