From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F40A22C21C1 for ; Sat, 28 Feb 2026 23:23:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772320986; cv=none; b=sErbXgwgcLmXNxKDjFyzujQ++u3p9Dwy+aPKmHO6GG9Z4v7GmXOJtlwg5otOt2yejercj8hpO3rxppuDD8zeC35o9KbCD8Ylqg0F+Uv8j4Uq5O85676xwJN0OetCQrQ4vEPkFGuG6meXU8B8Ac71tVpFsINv0kz+ZG32Q4WE30I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772320986; c=relaxed/simple; bh=HtipnwZKLnUK0x1kI7ml/XGP7yxeVEVDo2xSQh6ZcAQ=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=uivY8FJPsXoeGym1AaUxoJYHP32msW9HKARPmb+RBc6aMpx31fPwavjbcWCU0QPMJbYEWw3+ZFXt197ol4ppdm9YZpkEDVelcUwt6PdKjv0f8sXe8OsqVt9u6LZDD1niF1IHjFXEKbjjZmD+mheglWtTwghoCyMsuJVIose0sj8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Ue83GOIn; arc=none smtp.client-ip=209.85.128.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Ue83GOIn" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-48371119eacso39246795e9.2 for ; Sat, 28 Feb 2026 15:23:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772320982; x=1772925782; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=84eJNEp6vvN1olc1qLpAO0h3fBelQAr4Y3eg29KdRtM=; b=Ue83GOInNsrX8gtQxbPtc2Mlpa2RMRBsfwO9P2YEg/HU0FjyRIka+dKfL5x2dvvikb te2fsfV8eZIYhzUT0DH0gZl4OLI4HaZpMQjwTck8/bkNMUR3TW1bx1O9lqmv6bGRkzaf 7Vv/qp7sRkJco6BqYAmrYNqOmSr+RD0Qw5I0+Wn3ND5vKb108RmUQyDVCSfJHvDoyu2u VaquBR6p29Ph9E9WdKzL/AosES3uBFL0tYiUujGrqI294XmcKKKQi/XQYfP9NpO6dcvR JK91YEuFoC+4y2KQytnAFLl0t6nI9ZgWSTZadClX1Eio0wDLXpSOpfh2gCfEH2LEjCFc VD3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772320982; x=1772925782; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=84eJNEp6vvN1olc1qLpAO0h3fBelQAr4Y3eg29KdRtM=; b=YcIAHe2LgfyDEks+cgoXZKTIUthdtSPZHCNzzx7vWKvsUwfKofKJzOX9JohAqOi6uw Wm5wm8FJjMILMjAEwAPeWiJUOdO/GvA8aEQoHJh+oyCjAPjNn/3t9Ydj4N9gIGtO1pof yDcMDy0e0reXtmZCznFuUS4fLzZPJCkFlCYG0VXs/PaiikswHZ0SVG2yOqZK79yBnnMw tBm94XwiSbg0cb6gIQzmVfaTCj9trCxCHALb3mGZr9ZK091CmXjqkouNiRKM8KWdgA9f 1QAWRuJYvKXXy0SHlSTPsrkLajFFIT7IPfeGOaUbt+zW8qSWcyF5+2fWykTkWQ273iHF eXLg== X-Gm-Message-State: AOJu0Yw3HpxnXV+L7KtYrz8a7a6h+4GcolKFrAisyrlrBVaYJeyIp4Kb om4okxYVvVy9deWOjd4JLvcgPV2amkn65asdQex4m0vt90oYvC0nStbclBdyZrwOfZY= X-Gm-Gg: ATEYQzzAzv/fWcjAqMHUSs8iAaym64YnXlR3P0YDe1EuplOlBWACX6KMc/Oviw3WYCy +9quYko32Xck2d07fyn+GO5cPxAAR1Zqz2ksosefW2v5dUd8u7srGWNQie6aRpGIyVQ5jlsR3MO zAcY+ZRS7R8E8NZ2KiyPJhHrsG5/ukpcupaDNDK37SJZfuzJmc2lRW/4NB2Bsq0cbUZ4bRAWTdX eUXHZjbtVRjXWHZvjW6Y7EhOiTiykisSUvFZI8PqtsXSJkyOovBZ4Dt/KZ+4oJF8+hOoJPJiEPb XVfmRYhT7q3KRDrcTOUbWWQFjeqdnDdqPx4GfG39USHWCMxwyM7ykDpeFu0ZaizgEBLJEPviEP+ vw+sgXCPsbcMMgfvXfLwz2BcCaucZsAw3qnOE7EhUM6s7Z8NqSZtAG/xrfbk8gHBgQqWgMfqA2o XrUAGIu0/ScrbVFEBAApfP0ASrx3TO0JivJnPtLR2DKfLrnIoqSJinTZWra6MfYI8DMv6QRslsQ 3ypTfk= X-Received: by 2002:a05:600c:46d5:b0:477:a36f:1a57 with SMTP id 5b1f17b1804b1-483c9bb7c16mr121675285e9.3.1772320981923; Sat, 28 Feb 2026 15:23:01 -0800 (PST) Received: from pc-kuba-l13.. (snat-2.cgn.sat-an.net. [176.222.226.2]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4399c70ed47sm18515680f8f.11.2026.02.28.15.23.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 Feb 2026 15:23:01 -0800 (PST) From: =?UTF-8?q?Jakub=20Van=C4=9Bk?= To: linux-kernel@vger.kernel.org, netdev@vger.kernel.org Cc: Andrew Lunn , Heiner Kallweit , Russell King , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Frank , Sai Krishna , Daniel Golle , =?UTF-8?q?Jakub=20Van=C4=9Bk?= Subject: [PATCH net-next v2 0/5] net: phy: Disable MDIO broadcast address on YT8821 Date: Sun, 1 Mar 2026 00:22:36 +0100 Message-ID: <20260228232241.1274236-1-linuxtardis@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- 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