On 10/13/2021 7:50 AM, Alvin Šipraga wrote:
From: Alvin Šipraga <alsi@xxxxxxxxxxxxxxx>
This patch adds a realtek-smi subdriver for the RTL8365MB-VC 4+1 port
10/100/1000M switch controller. The driver has been developed based on a
GPL-licensed OS-agnostic Realtek vendor driver known as rtl8367c found
in the OpenWrt source tree.
Despite the name, the RTL8365MB-VC has an entirely different register
layout to the already-supported RTL8366RB ASIC. Notwithstanding this,
the structure of the rtl8365mb subdriver is based on the rtl8366rb
subdriver and makes use of the rtl8366 helper library for setup of the
SMI interface and handling of MIB counters. Like the 'rb, it establishes
its own irqchip to handle cascaded PHY link status interrupts.
The RTL8365MB-VC switch is capable of offloading a large number of
features from the software, but this patch introduces only the most
basic DSA driver functionality. The ports always function as standalone
ports, with bridging handled in software.
One more thing. Realtek's nomenclature for switches makes it hard to
know exactly what other ASICs might be supported by this driver. The
vendor driver goes by the name rtl8367c, but as far as I can tell, no
chip actually exists under this name. As such, the subdriver is named
rtl8365mb to emphasize the potentially limited support. But it is clear
from the vendor sources that a number of other more advanced switches
share a similar register layout, and further support should not be too
hard to add given access to the relevant hardware. With this in mind,
the subdriver has been written with as few assumptions about the
particular chip as is reasonable. But the RTL8365MB-VC is the only
hardware I have available, so some further work is surely needed.
Co-developed-by: Michael Rasmussen <mir@xxxxxxxxxxxxxxx>
Signed-off-by: Michael Rasmussen <mir@xxxxxxxxxxxxxxx>
Signed-off-by: Alvin Šipraga <alsi@xxxxxxxxxxxxxxx>
Reviewed-by: Vladimir Oltean <olteanv@xxxxxxxxx>
Reviewed-by: Florian Fainelli <f.fainelli@xxxxxxxxx>
Nice work! If you happen to spin a v3, maybe consider moving the IRQ
chip setup to an earlier point in the driver probe since it is a path
that can return -EPROBE_DEFER?
--
Florian
