netdev - 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:   Sat, 18 Dec 2021 05:14:12 -0300
From:   Luiz Angelo Daros de Luca <luizluca@...il.com>
To:     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,
        arinc.unal@...nc9.com
Subject: net: dsa: realtek: MDIO interface and RTL8367S

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.

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 rtl8365mb 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