netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jisheng Zhang <jszhang@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Russell King <linux@armlinux.org.uk>,
	Florian Fainelli <florian.fainelli@broadcom.com>,
	Jakub Kicinski <kuba@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org
Subject: Re: [RFC] mdio demux multiplexer driver
Date: Sat, 16 Aug 2025 13:26:19 +0800	[thread overview]
Message-ID: <aKAWe27bDtjBIkp-@xhacker> (raw)
In-Reply-To: <5e3c5d70-f4fd-46db-90a1-e8be0ae5f750@lunn.ch>

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

  reply	other threads:[~2025-08-16  5:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-13  0:58 [RFC] mdio demux multiplexer driver Jisheng Zhang
2025-08-15  3:51 ` Andrew Lunn
2025-08-16  5:26   ` Jisheng Zhang [this message]
2025-08-16 14:52     ` Andrew Lunn
2025-08-18 15:39       ` Jisheng Zhang
2025-08-18 16:21         ` Russell King (Oracle)
2025-08-18 16:27         ` Andrew Lunn
2025-08-20 15:44           ` Jisheng Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aKAWe27bDtjBIkp-@xhacker \
    --to=jszhang@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=florian.fainelli@broadcom.com \
    --cc=kuba@kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).