From: Andrew Lunn <andrew@lunn.ch>
To: "Jakub Vaněk" <linuxtardis@gmail.com>
Cc: Frank <Frank.Sae@motor-comm.com>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Sai Krishna <saikrishnag@marvell.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v1] net: phy: motorcomm: yt8821: disable MDIO broadcast address 0
Date: Sun, 22 Feb 2026 01:16:51 +0100 [thread overview]
Message-ID: <3e9812a5-401b-400d-9d9b-eec8ec8d0acf@lunn.ch> (raw)
In-Reply-To: <d3bb9c36-5a0e-4339-901d-2dd21bdba395@gmail.com>
On Sun, Feb 22, 2026 at 12:46:53AM +0100, Jakub Vaněk wrote:
> The YT8821 PHY responds on two MDIO addresses by default: the address
> selected by its strapping pins and the broadcast address 0.
>
> On platforms where another PHY is hardwired to respond only on address 0
> (e.g. the internal Gigabit PHY in the MediaTek MT7981B SoC), this can lead
> to MDIO bus conflicts. The YT8821 may incorrectly respond to transactions
> intended for the other PHY, leaving it in an inconsistent state. The
> following issues were observed on a Cudy M3000 router:
I don't think you can reliably fix this in this way.
Linux enumerates and probes the bus in two different ways.
When mdiobus_register() is used, it enumerates the bus in address
order. So the probe of the internal Gigabit PHY will happen first at
address 0, and then the YT8821 will later be probed, by which times it
has already caused bus conflicts and potentially messed up the
internal PHY.
If of_mdiobus_register() is used, it first probes the PHYs listed in
DT, based on the order of the child nodes. If the child nodes are
first reg=<0> for the internal PHY, and then reg=<??> for the YT8821,
you have the same issue, bus conflicts. And ordering the nodes this
way is part of the DT coding style...
Now you could vary carefully put the nodes in the correct order, with
a big fat warning that the board design is FUBAR and will only work
with the nodes in this specific order. And you need another big fat
warning in the YT8821 driver that just because broadcast is turned off
at probe does not on its own make it reliable, it could of already
destroyed another PHYs configuration by the time the driver probes.
So to me, this sounds unreliable, a potential foot gun.
I can think of two better ways to fix this:
1) In the bootloader. If the bootloader supports TFTP booting, or any
networking, it needs to fix the same issue. It can poke around on the
MDIO bus before it probes the PHYs.
2) Split of_mdiobus_register() into two, so that you can register the
bus, then do some platform specific fixups to disable the broadcast
address in the PHY, and then do the second half of
of_mdiobus_register() which probes the PHYs, once it is safe to use
address 0 on the bus.
I prefer 1).
Andrew
next prev parent reply other threads:[~2026-02-22 0:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-21 23:46 [PATCH net v1] net: phy: motorcomm: yt8821: disable MDIO broadcast address 0 Jakub Vaněk
2026-02-22 0:16 ` Andrew Lunn [this message]
2026-02-23 20:06 ` Jakub Vaněk
2026-02-22 0:18 ` Russell King (Oracle)
2026-02-22 2:04 ` Jakub Vaněk
2026-02-22 2:32 ` Jakub Vaněk
2026-02-22 3:35 ` Andrew Lunn
2026-02-22 4:22 ` Jakub Vaněk
2026-02-22 8:28 ` Russell King (Oracle)
2026-02-22 9:52 ` Jakub Vaněk
2026-02-22 15:15 ` Andrew Lunn
2026-02-22 19:12 ` Jakub Vaněk
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=3e9812a5-401b-400d-9d9b-eec8ec8d0acf@lunn.ch \
--to=andrew@lunn.ch \
--cc=Frank.Sae@motor-comm.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linuxtardis@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saikrishnag@marvell.com \
/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