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-next>] [day] [month] [year] [list]
Message-Id: <20211216201342.25587-1-luizluca@gmail.com>
Date:   Thu, 16 Dec 2021 17:13:29 -0300
From:   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: [PATCH net-next 00/13] 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. 

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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ