kernel/git/next/linux-next.git/drivers/net/mdio, branch master

net: mdio: mux-meson-g12a: Make sure clk_init_data is fully initialized

2026-09-08T10:14:39+00:00

The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. Make sure all members are fully initialized, to avoid such bugs, and to prevent future breakage when converting drivers to a different method for specifying the parents. Signed-off-by: Geert Uytterhoeven Reviewed-by: Brian Masney Link: https://patch.msgid.link/98e2b71c333fea0ed59bf615c818cb7b56e2f2b5.1788425654.git.geert+renesas@glider.be Signed-off-by: Paolo Abeni

net: mdio: bcm-unimac: Remove comma after sentinel-entry in match-table

2026-09-07T23:57:10+00:00

Since sentinel is the last entry and we do not expect further entries following it, remove the comma. Signed-off-by: Siddharth Vadapalli Signed-off-by: Jakub Kicinski

net: mdio: bcm-iproc: Remove comma after sentinel-entry in match-table

2026-09-07T23:57:10+00:00

Since sentinel is the last entry and we do not expect further entries following it, remove the comma. Signed-off-by: Siddharth Vadapalli Signed-off-by: Jakub Kicinski

net: mdio: realtek-rtl9300: reword Kconfig and module description

2026-09-03T01:57:55+00:00

The Realtek MDIO driver has been enhanced to support multiple devices from the RTL83xx/RTL93xx series. Reword Kconfig and module description accordingly. Signed-off-by: Markus Stockhausen Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260831143439.2404484-14-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski

net: mdio: realtek-rtl9300: Add support for RTL839x

2026-09-03T01:57:55+00:00

The MDIO driver has been prepared for multiple device support. Add all required bits for the RTL839x (aka cypress) series. This is straightforward but some things are worth mentioning. - The device has a lot in common with the RTL931x series. It has 8192 (Realtek) pages and 7 MMIO registers. - There are two SMI buses for 1G PHYs. Neither the bus nor address map registers exist. - The hardware has not much to configure. So the setup_controller() function is not needed. - The bit specific registers (polling & port_mask) are 2x32 bit wide. The ports 0..31 got to and the ports 32..51 go to . - C22 read/write functions must be called with PARK_PAGE = 0. Keep code clean and avoid setting it to zero, matching the behavior of the RTL9310 logic. - As per SDK the broadcast register allows to write to multiple ports at the same time. Unlike RTL9310 where this is filled with a bit mask for the current port RTL8390 does not use it for normal reads/writes. It is simply set to 0 like the SDK does. - The SDK fills the EXT_PAGE register with 0x1ff for C22 access and with 0x0 for C45 access. The reason for this is currently unknown and a meaningful name can not be given. Align the driver coding with the RTL9300_PHY_CTRL_PARK_PAGE settings and simply fill the hardcoded value. Signed-off-by: Markus Stockhausen Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260831143439.2404484-13-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski

net: mdio: realtek-rtl9300: Add support for RTL838x

2026-09-03T01:57:55+00:00

The MDIO driver has been prepared for multiple device support. Add all required bits for the RTL838x (aka maple) series. This is straightforward but some things are worth mentioning. - The device has a lot in common with the RTL930x series. It has 28 ports, 4096 (Realtek) pages and 4 MMIO registers. With this a lot of the existing RTL9300 defines could be reused. But to avoid confusion and for better readability duplicate the defines with a proper prefix. - The MDIO engine has no fail bit. Thus the mask is set to zero. - There is only one SMI bus for 1G PHYs. No bus_map_base register exists. - The setup_controller() function needs no C45 configuration as polling only works in C22 mode - The PHY access must be activated by a special register flag. Signed-off-by: Markus Stockhausen Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260831143439.2404484-12-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski

net: mdio: realtek-rtl9300: Open up C22 and C45 space in parallel

2026-09-03T01:57:54+00:00

Until now the MDIO driver supports either access to the C22 or to the C45 address space of the PHYs. This is due to the fact that the polling configuration favours one of the address spaces and limits access to the other space. E.g. when polling is set to C22 most of the C45 space can not be accessed. There are however some exceptions from that. EEE register access is allowed independently from the polling mode [1]. As the downstream driver already allows parallel C22/C45 access [2] do this in upstream too. [1] https://github.com/openwrt/openwrt/blob/main/target/linux/realtek/files-6.18/drivers/net/phy/realtek/realtek_multiport.c#L349 [2] https://github.com/openwrt/openwrt/blob/main/target/linux/realtek/files-6.18/drivers/net/mdio/mdio-realtek-otto.c#L1072 Signed-off-by: Markus Stockhausen Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260831143439.2404484-11-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski

net: mdio: realtek-rtl9300: Increase MDIO timeout

2026-09-03T01:57:54+00:00

RTL838x devices with 28 ports produce PHY access timeout errors during one of three boots while waiting for MDIO command completion. This is currently set to 1ms. Background: Access to the Realtek Otto ethernet MDIO bus must wait for a free slot between two hardware polls. The polling sequence consists of at least 17 commands on the RTL838x devices. This delay can be nicely seen when disabling polling completely. The following times are measured on a bus running on the default 2.5MHz. Time measured is from the last register write that sets the command-start-bit until the hardware responds with the command-finished-bit set. - average c22 read with polling enabled on all ports: ~380us - average c22 read with polling enabled on one port: ~380us - average c22 read with polling completely disabled: ~180us For this bus frequency the bare hardware runtime for a single command (32 bit preamble + 32 bit data) is ~25us. So the hardware adds quite some overhead. On top of this comes the fact that the RTL838x devices are low on resources (500Mhz 4Kec core with 16K cache). Increase the timeout to 10ms to be on the safe side. Remark! In a future patch the bus clock frequency will be made configurable with a minimum frequency of 1.25MHz. Setting this (e.g. for debugging purposes) doubles the command run times but will safely stay below 10ms. Signed-off-by: Markus Stockhausen Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260831143439.2404484-10-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski

net: mdio: realtek-rtl9300: Add page tracking

2026-09-03T01:57:42+00:00

The hardware polling unit of the Realtek switches has a very special handling for c22 PHY register 31 (aka Realtek page register) in place. - On the RTL838x it is permanently reset to zero. - On other devices there is some magic saving/restoring (aka parking) in the background in place. This makes access to PHYs a gamble. It is vital to keep the polling alive so the MAC layer can rely on consistent data. Intercept access to c22 register 31 and handle it internally. Store the desired value for each port in the driver. When issuing hardware access to other registers add the page to the command towards the controller. Given this, the hardware will run two c22 commands that are not interrupted by polling. ... hardware poll ... phy_write(phy, 31, page) phy_write(phy, reg, value) ... hardware poll ... Looking at this implementation one might argue that disabling/enabling polling might be a cleaner solution. But one must remember that - This driver differentiates clearly between C22 and C45 buses. During probing it enables only one of the protocols for a bus. - All known devices run RTL8218 (B/D/E) or RTL8214FC on 1G - RTL839x gives link flapping when deactivating polling for a port So a solution for a Realtek-only ecosystem is required. This commit copies the downstream-proven driver-only page handling patch without any new MDIO callbacks and is the lowest common denominator. If a non-Realtek PHY is identified on a c22 bus the attachment aborts. It should be noted that bus scan runs with the page handling already in place before the check in notify_phy_attach(). This is accepted for now. Remark: To keep this simple, writes to register 31 are only accepted if they are lower than the device specific raw page - 0..4094/8190. Otherwise -EINVAL is returned. Under the above assumption (Only 1G Realtek PHYs on a c22 bus) this is no limitation. Signed-off-by: Markus Stockhausen Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260831143439.2404484-9-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski

net: mdio: realtek-rtl9300: Configure hardware polling during probing

2026-09-03T01:57:08+00:00

During PHY probing and configuration complex configuration sequences might be issued and firmware might be loaded. Hardware polling can interfere badly with that. E.g. a hardware polling MMD c45 over c22 request might break an ongoing firmware loading sequence. To avoid such issues the polling of the Realtek Otto switches can be (de)activated with one or two 32 bit mask registers. Each bit enables (=1) or disables (=0) the polling of the corresponding port. Make use of this as follows: - Disable polling for all ports when the MDIO driver starts. - Reenable polling just after the PHY has been attached. - Disable polling just before the PHY is being detached. This synchronizes the kernel and hardware polling to some extent. It gracefully handles deferred probing of PHYs in case the driver is loaded asynchronously during boot. Additionally it brings the hardware polling into a consistent operation mode for devices where U-Boot does not take care. Important notes about the implementation: Realtek is very inconsistent about its register naming. RTL930x uses SMI_POLL_CTRL for polling control while it is SMI_PORT_POLLING_CTRL on RTL931x. Keep these vendor names. These devices do not support power management for the whole system. So mdio_bus_phy_resume() is not used and it is not required to disable/enable hardware polling for that usecase. These devices have no CPU MAC to PHY design. Thus abort phy_attach() in case PHYs are not mapped to valid switch ports. All MDIO bus commands will fail afterwards, leaving it in an unusable state. Enabling/disabling hardware polling is a simple regmap bit access. For this it is enough to rely on the regmap internal lock. This polling enabling/disabling does not solve the current inability of the driver to handle C45-over-C22 access during normal operation. For all existing designs this is not needed. [1] https://github.com/openwrt/openwrt/blob/main/target/linux/realtek/files-6.18/drivers/net/mdio/mdio-realtek-otto.c#L818 [2] https://lore.kernel.org/netdev/680696024a8648535ce6dee771fe4de67802e0e8.1769053496.git.daniel@makrotopia.org/ Signed-off-by: Markus Stockhausen Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260831143439.2404484-8-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski