public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: "Jakub Vaněk" <linuxtardis@gmail.com>
To: linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Cc: "Andrew Lunn" <andrew@lunn.ch>,
	"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>,
	Frank <Frank.Sae@motor-comm.com>,
	"Sai Krishna" <saikrishnag@marvell.com>,
	"Daniel Golle" <daniel@makrotopia.org>,
	"Jakub Vaněk" <linuxtardis@gmail.com>
Subject: [PATCH net-next v2 0/5] net: phy: Disable MDIO broadcast address on YT8821
Date: Sun,  1 Mar 2026 00:22:36 +0100	[thread overview]
Message-ID: <20260228232241.1274236-1-linuxtardis@gmail.com> (raw)

Hello,

this series is a rewrite of patch [1], which attempted to make the
Motorcomm YT8821 PHY operate reliably in the Cudy M3000 WiFi router.

Background
==========

The issue on the Cudy M3000 is an MDIO address collision at address 0:

 * The MediaTek MT7981B internal Gigabit PHY appears to be hardwired
   to respond only at MDIO address 0.

 * The Motorcomm YT8821 external PHY responds, by default, at address 0
   in addition to address 1 selected by its strapping pins.

At a minimum, this means that MDIO transactions intended for the
MT7981B PHY are also interpreted by the YT8821, which causes the
YT8821 to not work reliably.

The YT8821 is not unique in this regard. At least two other vendors
ship PHYs with similar behavior:

 * Realtek RTL8221B-VB-CG
 * Micrel KSZ8081

It appears to me that multiple vendors may have interpreted IEEE 802.3
Clause 22.2.4.5.5 to mean that MDIO address 0 is a reserved broadcast
address ("A PHY [...] shall always respond to transactions addressed
to PHY Address zero"). However, the omitted part of that sentence
limits the scope, and it does not apply to many PHY types.

What this series does
=====================

The goal of this series is to reconfigure the YT8821 early enough so
that it stops responding on address 0 before the kernel performs the
first access to MDIO address 0.

The approach is as follows:

 1. Patches 1 and 2 modify the MDIO bus probing order so that address 0
    is scanned last. This allows PHY fixups to reconfigure PHYs found
    at addresses 1-31 before address 0 is probed. The core idea was
    suggested by @dangowrt on OpenWrt GitHub [2].

 2. Patches 3-5 implement the required PHY fixup for the YT8821.
    They introduce infrastructure for an "address 0 fixup" that can
    be reused by other affected PHYs.

I initially attempted to use the driver .probe() callback. However,
testing showed that this is insufficient: if the YT8821 driver is
built as a module, the .probe() callback does not run early
enough (i.e. before the MT7981B PHY is initialized).

Why this is done in the kernel
==============================

In the v1 discussion [1], the conclusion was that this should ideally
be handled in the bootloader. However, this is not always practical
for OpenWrt deployments:

 * On the Cudy M3000, replacing the stock U-Boot is possible, but
   doing so removes the ability to easily revert to the vendor
   firmware using the procedure described in [3].

 * On other platforms, replacing the bootloader may not be possible, and
   so OpenWrt may need to have a kernel-based workaround for them [2].

Testing
=======

The series was tested against the v6.12 kernel currently used by
OpenWrt main. It resolves the PHY issues on the Cudy M3000 with the
Motorcomm PHY and does not break networking on the Cudy WR3000H,
which uses a different Realtek PHY.

I also verified that no MDIO access to address 0 occurs before the
YT8821 is reconfigured to stop responding on that address.

The series is rebased on top of v7.0-rc1 and build-tested there.

[1]: https://lore.kernel.org/all/d3bb9c36-5a0e-4339-901d-2dd21bdba395@gmail.com/#t
[2]: https://github.com/openwrt/openwrt/pull/21584#issuecomment-3941868545
[3]: https://www.cudy.com/en-eu/blogs/faq/how-to-recovery-the-cudy-router-from-openwrt-firmware-to-cudy-official-firmware

Signed-off-by: Jakub Vaněk <linuxtardis@gmail.com>
---
Changes in v2:
- Introduce changes into the PHY core that allow the broadcast
  addresses to be disabled before the first address collision
  occurs.
- Move the early disabling of the broadcast address from the
  YT8821 .probe() callback into a PHY fixup.
- In motorcomm.c, use ytphy_read_ext_with_lock() for the disabling
  as it takes the MDIO bus lock.

Jakub Vaněk (5):
  net: mdio_bus: Scan buses in reverse order (31 -> 0)
  of: mdio: Scan PHY address 0 last
  net: phy: Support PHY fixups on Clause 45 PHYs
  net: phy: Add infrastructure for PHY address 0 fixups
  net: phy: motorcomm: yt8821: Disable MDIO broadcast

 drivers/net/mdio/of_mdio.c          | 35 +++++++++++++++--
 drivers/net/phy/Makefile            |  3 +-
 drivers/net/phy/mdio_bus_provider.c | 14 ++++++-
 drivers/net/phy/motorcomm.c         | 29 ++++++++++++++
 drivers/net/phy/phy_common_fixups.c | 59 ++++++++++++++++++++++++++++
 drivers/net/phy/phy_device.c        | 60 ++++++++++++++++++++---------
 drivers/net/phy/phylib-internal.h   |  2 +
 7 files changed, 176 insertions(+), 26 deletions(-)
 create mode 100644 drivers/net/phy/phy_common_fixups.c

-- 
2.43.0


             reply	other threads:[~2026-02-28 23:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-28 23:22 Jakub Vaněk [this message]
2026-02-28 23:22 ` [PATCH net-next v2 1/5] net: mdiobus: Scan buses in reverse order (31 -> 0) Jakub Vaněk
2026-03-01 15:11   ` Andrew Lunn
2026-03-01 17:03   ` Russell King (Oracle)
2026-03-01 17:24     ` Jakub Vaněk
2026-02-28 23:22 ` [PATCH net-next v2 2/5] of: mdio: Scan PHY address 0 last Jakub Vaněk
2026-02-28 23:22 ` [PATCH net-next v2 3/5] net: phy: Support PHY fixups on Clause 45 PHYs Jakub Vaněk
2026-02-28 23:22 ` [PATCH net-next v2 4/5] net: phy: Add infrastructure for PHY address 0 fixups Jakub Vaněk
2026-02-28 23:22 ` [PATCH net-next v2 5/5] net: phy: motorcomm: yt8821: Disable MDIO broadcast Jakub Vaněk
2026-03-01  2:43   ` kernel test robot
2026-03-01 16:06 ` [PATCH net-next v2 0/5] net: phy: Disable MDIO broadcast address on YT8821 Andrew Lunn
2026-03-01 17:07   ` Russell King (Oracle)
2026-03-01 17:15   ` 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=20260228232241.1274236-1-linuxtardis@gmail.com \
    --to=linuxtardis@gmail.com \
    --cc=Frank.Sae@motor-comm.com \
    --cc=andrew@lunn.ch \
    --cc=daniel@makrotopia.org \
    --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=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