From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Jisheng Zhang <jszhang@kernel.org>
Cc: Andrew Lunn <andrew@lunn.ch>,
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: Mon, 18 Aug 2025 17:21:10 +0100 [thread overview]
Message-ID: <aKNS9uPpyeQgWrBY@shell.armlinux.org.uk> (raw)
In-Reply-To: <aKNJN4sBfi_YAjrF@xhacker>
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!
next prev parent reply other threads:[~2025-08-18 16:21 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
2025-08-16 14:52 ` Andrew Lunn
2025-08-18 15:39 ` Jisheng Zhang
2025-08-18 16:21 ` Russell King (Oracle) [this message]
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=aKNS9uPpyeQgWrBY@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=florian.fainelli@broadcom.com \
--cc=jszhang@kernel.org \
--cc=kuba@kernel.org \
--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).