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] [day] [month] [year] [list]

Message-ID: <c40dd405-9549-40c9-8cfd-88dd0b1342da@lunn.ch>
Date: Mon, 18 Aug 2025 18:27:33 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Jisheng Zhang <jszhang@...nel.org>
Cc: Russell King <linux@...linux.org.uk>,
	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

> > Both Ethernet and MDIO hardware exists, even if it is not used. I
> > would separate the drivers. Have a MAC driver and an MDIO driver. List
> > them as separate entities in DT. Always probe the MDIO0 driver. It can
> > set the MUX registers. Don't probe MDIO1 driver. Even if it does
> > probe, you know MDIO0 is one to be used, so MDIO1 can still set the
> > MUX to point to MDIO0.
> > 
> > How messy is the address space? Are the MDIO registers in the middle
> > of the MAC registers? Is this a standard, off the shelf MAC/MDIO IP?
> > stmmac? Or something currently without a driver? If you are dealing
> 
> 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 you only really have problems when MAC0 is not used. Are there any
boards actually designed that way? If there are no such boards at the
moment, you can delay handling that until later.

When later arrives, i would probably look at refactoring the stmmac
MDIO code into a library. The stmmac driver can use the library, and
you can add a new MDIO only driver around the library for when MAC0 is
not used, but you need the MDIO bus.

For the moment, you can add setting the MUX register in the stmmac
glue driver.

	Andrew