> >> + properties: > >> + realtek,port: > >> + $ref: /schemas/types.yaml#/definitions/uint32 > >> + description: > >> + The MDIO communication on the RTL9300 is abstracted by the switch. At > >> + the software level communication uses the switch port to address the > >> + PHY with the actual MDIO bus and address having been setup via the > >> + parent mdio-bus and reg property. > > I don't quite get why this cannot be the 'reg' property. I understood that > > 'reg' of this node is not really used? Or you meant here this 'reg', not > > parent's 'reg'? > > It's is a bit confusing (any suggestions for improving the description > and/or commit message are welcome). I don't know if it will actually help, but.... We have two entangled configurations here. 1) You have 4 MDIO busses which you need to describe using mdio.yaml In this binding, reg is the address of the device on the bus, in the range 0-31. 2) The hardware was a pool of PHYs which you can map to address on the MDIO busses. Rather than combining them, maybe it would be better to keep them separate. It is probably more error prone, but simpler to understand. And hopefully errors result in PHYs not being found during probe, so the problems are obvious. Maybe you can actually use phandles. You have the usual MDIO bus nodes: mdio@5c030000 { #address-cells = <1>; #size-cells = <0>; ethphy0: ethernet-phy@1 { reg = <1>; }; ethphy1: ethernet-phy@3 { reg = <3>; }; }; mdio@5c040000 { #address-cells = <1>; #size-cells = <0>; ethphy2: ethernet-phy@1 { reg = <1>; }; ethphy3: ethernet-phy@3 { reg = <3>; }; }; mdio@5c050000 { ... } mdio@5c060000 { ... } And then a node which is a list of PHY phandles: [ðphy0, ðphy1, ðphy2, ðphy3, ....] The 0th entry in the list tells you have to map the 0th PHY in the pool to an MDIO bus and address. Follow the phandle to get the MDIO bus and the address on the bus. Andrew