kernel/linux.git/drivers/net/mdio, branch v7.2-rc1

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

2026-06-13T00:24:11+00:00

The MDIO driver has been prepared for multiple device support. Add all required bits for the RTL931x (aka mango) series. This is straightforward but some things are worth to be mentioned. - In contrast to RTL930x the I/O register has the input/output fields swapped. Upper 16 bits are for read/outputs, and the lower 16 bits are for write/inputs. - The supported "pages" are 8192 and thus the raw page is 8191 - The devices support up to 56 ports. Thus the MAX_PORTS definition is increased by this commit. - There are multiple global SMI controller registers with a different layout from RTL930x devices. Therefore a separate setup_controller() callback is added. Reviewed-by: Andrew Lunn Signed-off-by: Markus Stockhausen Link: https://patch.msgid.link/20260610194145.4153668-6-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski

net: mdio: realtek-rtl9300: Add registers for high port count models

2026-06-13T00:24:11+00:00

The high port count models of the Realtek Otto switches have additional registers to instrument the MDIO controller. These are: - High port mask: A bitfield that extends the already existing low port mask to select ports starting from 32. - Broadcast: This takes the port number during reads on the RTL931x. - Extended page: Some additional page info. The SDK does not give much information about this. Basically some fixed value must be written into it during access. Reviewed-by: Andrew Lunn Signed-off-by: Markus Stockhausen Link: https://patch.msgid.link/20260610194145.4153668-5-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski

net: mdio: realtek-rtl9300: Make otto_emdio_read_cmd() generic

2026-06-13T00:24:11+00:00

The otto_emdio_read_cmd() helper still uses RTL9300 specific properties. This cannot be made generic as the I/O register has different layouts for the different SoCs. E.g. - RTL930x: data in bits 31-16, data out bits 15-0 - RTL931x: data in bits 15-0, data out bits 31-16 Add a mask parameter to the function signature and fill it properly in the callers. As the masks will always have bits set from constant defines, there is no need for a consistency check. Reviewed-by: Maxime Chevallier Signed-off-by: Markus Stockhausen Link: https://patch.msgid.link/20260610194145.4153668-4-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski

net: mdio: realtek-rtl9300: Add prefix to register field defines

2026-06-13T00:24:11+00:00

The current Realtek Otto MDIO driver has some define leftovers without a SoC prefix. When adding new devices there will be an overlap for some of them. Sort this out as follows: - PHY_CTRL_CMD/PHY_CTRL_MMD_DEVAD/PHY_CTRL_MMD_REG are common for all series. Leave them as is but move them into a separate block. - Add RTL9300 prefix to all other defines and adapt the callers. Reviewed-by: Andrew Lunn Signed-off-by: Markus Stockhausen Link: https://patch.msgid.link/20260610194145.4153668-3-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski

net: mdio: realtek-rtl9300: Correctly handle ethernet-phy-package

2026-06-06T01:38:56+00:00

Realtek Otto switches usually make use of multiport PHYs (e.g. 8 port 1G RTL8218D or 4 port 2.5G RTL8224). The device tree can describe this fact via an "ethernet-phy-package" node that resides between the bus and the PHY node. When looking up the device tree bus node via the chain port->phy->parent the driver totally ignores the existence of a PHY package. Enhance the lookup to take care of this feature. Link: https://github.com/openwrt/openwrt/pull/23591 Signed-off-by: Manuel Stocker Signed-off-by: Markus Stockhausen Link: https://patch.msgid.link/20260603175924.123019-8-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski

net: mdio: realtek-rtl9300: reorder controller setup

2026-06-06T01:38:55+00:00

After the former refactoring the existing otto_emdio_9300_mdiobus_init() contains only the c22/c45 bus mode setup. Like the topology setup this must run before bus registration. Otherwise the bus does not "speak" the right protocol for PHY setup. This setup is device-specific and other SoCs will need to set up other register bits in the controller in the future. Therefore - Relocate c22/c45 device tree readout to the very beginning of the probing - Add a new device-specific setup_controller() into the info structure. - Relocate otto_emdio_priv to satisfy the new info structure dependency. - Rename otto_emdio_9300_mdiobus_init accordingly and add it to the RTL9300 info structure. At the same time, adapt register naming for the function to make it clear that it only applies to this SoC. - Call setup_controller() prior to bus registration. Signed-off-by: Markus Stockhausen Link: https://patch.msgid.link/20260603175924.123019-7-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski

net: mdio: realtek-rtl9300: relocate c22/c45 device tree readout

2026-06-06T01:38:55+00:00

otto_emdio_map_ports() is the central place to lookup the topology and the properties of the Realtek ethernet MDIO controller from the device tree. Deviating from this the c22/c45 detection via "ethernet-phy-ieee802.3-c45" is running separately in otto_emdio_probe_one(). It loops over the same nodes, just at a later point in time. There is no benefit to divide this setup and to have a time window where the data structure is only filled partially. Additionally it uses the "fwnode" API. Consolidate the setup and convert it to the "of" API. Remark. This is a subtle change for dangling PHY nodes (not referenced by ethernet-ports). Before this commit all PHY nodes were evaluated for c45 setup, now only the referenced ones. Signed-off-by: Markus Stockhausen Link: https://patch.msgid.link/20260603175924.123019-6-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski

net: mdio: realtek-rtl9300: relocate topology setup

2026-06-06T01:38:55+00:00

Until now the driver sets up the port to bus/address topology of the controller after all buses are set up via otto_emdio_probe_one(). This does not work for devices where U-Boot skips this setup. It is not only needed for the hardware internal background PHY polling engine but it is essential for access to the PHYs during probing. Depending on the SoC type there exist two different register arrays - Bus mapping registers (RTL930x, RTL931x) define to which bus the port is attached. E.g. [1] - Address mapping registers (RTL838x, RTL930x, RTL931x) define to which address of the bus the port is attached. E.g. [2] Relocate the topology setup and make it generic. For this - Define device-specific bus_base/addr_base attributes that give the register base address where the mapping lives. In case one or both are not given the SoC does not support this specific type of mapping. - Create a helper otto_emdio_setup_topology() that writes the detected topology to the registers. - Call this helper prior to otto_emdio_probe_one(). - Remove unneeded code from otto_emdio_9300_mdiobus_init(). - Due to the added prefixes, increase define indentation Subtle change: The old coding used regmap_bulk_write and silently wrote bus=0/address=0 to mapping registers for ports that are out of scope. The new coding leaves those untouched. [1] https://svanheule.net/realtek/longan/register/smi_port0_15_polling_sel [2] https://svanheule.net/realtek/longan/register/smi_port0_5_addr_ctrl Signed-off-by: Markus Stockhausen Link: https://patch.msgid.link/20260603175924.123019-5-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski

net: mdio: realtek-rtl9300: harden otto_emdio_probe_one()

2026-06-06T01:38:55+00:00

The bus probing of the MDIO driver uses a two stage approach. 1. The device tree "ethernet-ports" node is scanned to build a mapping between ports and PHYs. 2. The children of the device tree "controller" are scanned to create the individual MDIO buses. The first step already checks the consistency of the PHY and bus nodes that are linked via the ports. But it might miss a dangling bus child node that is not linked. Step two simply iterates over all bus child nodes and might read malformed data from nodes not checked in step one. Harden this and return a meaningful error message. Signed-off-by: Markus Stockhausen Link: https://patch.msgid.link/20260603175924.123019-4-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski

net: mdio: realtek-rtl9300: harden otto_emdio_map_ports()

2026-06-06T01:38:55+00:00

Due to its design the MDIO driver needs to set up a port to bus/address mapping during probing. The "ethernet-ports" subnodes are scanned and from the "phy-handle" property the MDIO nodes are looked up. In case of a malformed device tree the driver might produce out-of-bounds accesses. The PHY address is not checked against the maximum supported address. Add a sanity check and drop the unneeded MAX_SMI_ADDR define. Signed-off-by: Markus Stockhausen Link: https://patch.msgid.link/20260603175924.123019-3-markus.stockhausen@gmx.de Signed-off-by: Jakub Kicinski