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: <aKAWe27bDtjBIkp-@xhacker>
Date: Sat, 16 Aug 2025 13:26:19 +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 Fri, Aug 15, 2025 at 05:51:41AM +0200, Andrew Lunn wrote:
> On Wed, Aug 13, 2025 at 08:58:06AM +0800, Jisheng Zhang wrote:
> > Hi,
> > 
> > Assume we have the following implementation:
> >           ----------
> >           |mmio reg|
> > 	  ----------
> >              |
> >  --------    |      -------
> >  | MAC0 |--MDIO-----| PHY |
> >  -------- |     |   -------
> >           |     |
> >  -------- |     |   -------
> >  | MAC1 |--     ----| PHY |
> >  --------           -------
> > 
> > Both MAC0 and MAC1 have MDIO bus masters, and tie together to
> > a single set of clock and data lines, which go to some PHYs. While
> > there's a mmio reg to control which MAC mdio master can operate
> > the single mdio clock and data lines, so only one MAC can operate
> > the mdio clock and data lines.
> 
> Where is the SoC boundary? Are the PHYs all external? So there is a
> single MDIO bus connected to the outside word? And all the PHYs are on
> that external MDIO bus?

Hi Andrew,

Thank you very much for the comments.

Yep, only one single MDIO bus connected to outside world, all the PHYs
are external and soldered on the board.

> 
> > We also need to fully support three use cases: only MAC0 + PHY is used
> > on board; only MAC1 + PHY is used on board; MAC0 + MAC1 + PHYs are
> > all used.
> 
> Linux does not care where a PHY is connected. A PHY is on "some" MDIO
> bus. It could be one associated to the MAC, it could be on the MDIO
> bus of some other MAC, it could be a GPIO bit banging MDIO bus. It
> could be an MDIO bus on its own, not associated to anything. The MAC
> DT node has phy-handle pointing to wherever the PHY is.
> 
> 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?

Bootloader? Bootloader guys says bootloader only needs to setup linux
bootenv such as DDR, necessary plls/clks, then read kernel Image from
external storage to memory and jump to it. mdio demux setting? No,
it's OS responsibility to setup it.

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.

Thanks