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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aKNJN4sBfi_YAjrF@xhacker>
Date: Mon, 18 Aug 2025 23:39:35 +0800
From: Jisheng Zhang <jszhang@...nel.org>
To: Andrew Lunn <andrew@...n.ch>
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

On Sat, Aug 16, 2025 at 04:52:25PM +0200, Andrew Lunn wrote:
> > > So, why not KISS. Hard code the MMIO reg so MAC0 is connected to the
> > > PHYs, and MAC1 just uses a phy-handle pointing to the PHYs on MAC0s
> > > MDIO bus.
> > 
> > Previously, I went with this solution. But then I met an issue -- who
> > does the harcoding? bootloader or linux kernel?
> 
> Linux. The bootloader can do it as well, e.g. for TFTP booting, but
> Linux should not rely on the bootloader.

+1

> 
> > Linux? This is what this email thread ask for comment -- How does
> > linux model this?
> > 
> > Another issue is: the hardcoding maybe different on different boards.
> > E.g If only MAC1 is used, we need to hardcode the MMIO reg to let
> > MAC1 MDIO master own the single MDIO DATA and CLK line.
> 
> 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.

> with a driver which already exists, it gets a bit messy.