Re: [PATCH net-next 00/13] net: dsa: realtek: MDIO interface and RTL8367S

Here's insight to what I've tested.

I tested an RTL8365MB-VC switch connected through SMI on an Asus 
RT-AC88U router.

I applied this patch series on net-next of 17 December 2021 using the 
OpenWrt master branch with slight modifications to run the net-next kernel.

First, I enabled every option introduced with this patch series to make 
sure there's nothing wrong with the compilation process.

Then, I disabled the MDIO & rtl8366rb subdriver options along with the 
now optional rtl4_a tag option. Therefore compiling the kernel with only 
the SMI, rtl8367c subdriver & rtl8_4 tag options enabled.

Everything compiles and the driver works as expected in both cases.

Cheers.
Arınç

On 16/12/2021 23:13, luizluca@gmail.com wrote:

This series refactors the current Realtek DSA driver to support MDIO
connected switchesand RTL8367S. RTL8367S is a 5+2 10/100/1000M Ethernet
switch, with one of those 2 external ports supporting SGMII/High-SGMII.

The old realtek-smi driver was linking subdrivers into a single
realtek-smi.ko After this series, each subdriver will be an independent
module required by either realtek-smi (platform driver) or the new
realtek-mdio (mdio driver). Both interface drivers (SMI or MDIO) are
independent, and they might even work side-by-side, although it will be
difficult to find such device. The subdriver can be individually
selected but only at buildtime, saving some storage space for custom
embedded systems.

The subdriver rtl8365mb was renamed to rtl8367c. rtl8367c is not a real
model, but it is the name Realtek uses for their driver that supports
RTL8365MB-VC, RTL8367S and other siblings. The subdriver name was not
exposed to userland, but now it will be used as the module name. If
there is a better name, this is the last opportunity to rename it again
without affecting userland.

Existing realtek-smi devices continue to work untouched during the
tests. The realtek-smi was moved into a realtek subdirectory, but it
normally does not break things.

I couldn't identify a fixed relation between port numbers (0..9) and
external interfaces (0..2), and I'm not sure if it is fixed for each
chip version or a device configuration. Until there is more info about
it, there is a new port property "realtek,ext-int" that can inform the
external interface.

The rtl8367c still can only use those external interface ports as a
single CPU port. Eventually, a different device could use one of those
ports as a downlink to a second switch or as a second CPU port. RTL8367S
has an SGMII external interface, but my test device (TP-Link Archer
C5v4) uses only the second RGMII interface. We need a test device with
more external ports in use before implementing those features.

The rtl8366rb subdriver was not tested with this patch series, but it
was only slightly touched. It would be nice to test it, especially in an
MDIO-connected switch.

Best,

Luiz