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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 17 Dec 2021 01:30:40 +0300
From:   Arınç ÜNAL <arinc.unal@...nc9.com>
To:     luizluca@...il.com, netdev@...r.kernel.org
Cc:     linus.walleij@...aro.org, andrew@...n.ch, vivien.didelot@...il.com,
        f.fainelli@...il.com, olteanv@...il.com, alsi@...g-olufsen.dk
Subject: 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@...il.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
> 
>