Sorting out the RTL9300 dt-bindings

[Chris Packham]

Hi,

As Krzysztof points out in [1] I seem to have made a bit of a mess with 
the mfd binding for the RTL9300 Ethernet switch with integrated CPU. I'm 
spinning up this email thread separately so as not to unnecessarily spam 
the netdev folks and to maybe appease google so it doesn't automatically 
get flagged as junk.

First off sorry for not providing a more complete binding initially, 
Krzysztof suggested doing so a few times but I was concentrating on 
landing the drivers.

The RTL9300 has these basic blocks:
- rtl9300
   |- cpu@0 - mips34kc
   |- soc@18000000
     |- intc
     |- spi-nor
     |- spi-nand
     |- timer
     |- gpio
     `- uart
   `- switch@1b000000
      |- ethernet-ports
      |- mdio
      |- i2c
      |- reset
      `- led/gpio

The CPU/soc can be disabled and the switch managed by an external CPU 
(register access over SPI I think, the docs are a bit vague).

I think I probably inferred too much from mfd/mscc,ocelot.yaml when I 
created mfd/realtek,rtl9301-switch.yaml.

I still think the switch@1b000000 needs to be "syscon", "simple-mfd" as 
that's how the reset and i2c blocks work and they're pretty independent 
of everything else.

I've currently described the mdio interface as a device on a simple bus 
although it could just be handled as a descendant of the switch block 
that a driver looks up as a child node (I've tried to keep the mdio 
driver independent for now but that's an implementation detail). It does 
need to reach out to the ethernet-ports to figure out the mapping of 
port to phy so it isn't independent.

I see a couple of paths forward
- keep adding the switch stuff to the mfd/realtek,rtl9301-switch.yaml
- move mfd/realtek,rtl9301-switch.yaml to net/realtek,rtl9301-switch.yaml
- keep mfd/realtek,rtl9301-switch.yaml with the i2c and reboot but have 
a $ref to a new binding under net/ (not sure what that'd look like).

There's only one in-tree user of this so I don't think we need to be too 
concerned about backwards compatibility. Downstream openwrt handles 
these devices way differently already.

Thanks,
Chris

--

[1] - 
https://lore.kernel.org/lkml/20250204-eccentric-deer-of-felicity-02b7ee@krzk-bin/