Hi Daniel,
On 18/12/2024 12:54, Daniel Golle wrote:
On Wed, Dec 18, 2024 at 11:44:59AM +1300, Chris Packham wrote:
[...]
+patternProperties:
+ '^ethernet-phy(@[a-f0-9]+)?':
+ type: object
+ $ref: ethernet-phy.yaml#
+
+ properties:
+ reg:
+ 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
+ realtek,smi-address property.
+
+ realtek,smi-address:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: SMI interface and address for the connected PHY
+ items:
+ - description: SMI interface number associated with the port.
+ - description: SMI address of the PHY for the port.
What speaks against describing the actual MDIO busses and addresses (ie.
the hardware) in Device Tree and setting up the hardware mapping between
ports and SMI bus and address by parsing the DSA switch port description
in the MDIO driver?
In that way you would not need the additional vendor-specific property
and on switches with high port density also avoid having to deal with
bogus "MDIO addresses" greater than 31.
I kind of expected this discussion.
The main problem is I couldn't figure out how to make that work.
Ultimately I still need to write the MDIO bus arrangement to hardware
and map back to a port number when doing MDIO accesses. Whether the
device-tree uses port number as the reg property and a vendor property
for the SMI address or does it the other way round I'd still need a
vendor property. There's also a complication that I've got one MDIO
controller that looks after more than one MDIO interface at the same
time. I'll have a bit of a think about it over the holidays and see if I
can come up with anything cleaner.
