All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/4] RFC: Realtek 83xx SMI driver core
@ 2017-11-05 23:19 Linus Walleij
  2017-11-05 23:19 ` [PATCH 1/4] RFC: net/dsa: Allow DSA PHYs to define link IRQs Linus Walleij
                   ` (4 more replies)
  0 siblings, 5 replies; 32+ messages in thread
From: Linus Walleij @ 2017-11-05 23:19 UTC (permalink / raw)
  To: Andrew Lunn, Vivien Didelot, Florian Fainelli; +Cc: netdev, Linus Walleij

Hi folks,

I'm working a bit on this. Since DSA is big, complex and hard for
a novice I just wanted to throw what I have in my tree out there
so you can take a look at how I hacked this up and give me some
help how to continue.

I am running it for trials on the D-Link DIR-685 and it looks
fun, but my ethernet driver for Gemini is not yet working so
I cannot really do proper testing. I'll get there I guess.

Example from dmesg:
realtek-smi 0.switch: deasserted RESET
realtek-smi 0.switch: found an RTL8366RB switch
DSA: switch 0 0 parsed
DSA: tree 0 parsed
realtek-smi 0.switch: RTL5937 ver 3 chip found
realtek-smi 0.switch: active low/falling IRQ
realtek-smi 0.switch: set MAC: CE:32:3B:FB:58:13
libphy: dsa slave smi: probed
RTL8366RB Gigabit Ethernet dsa-0.0:00: attached PHY driver [RTL8366RB Gigabit Ethernet] (mii_bus:phy_addr=dsa-0.0:00, irq=37)
RTL8366RB Gigabit Ethernet dsa-0.0:01: attached PHY driver [RTL8366RB Gigabit Ethernet] (mii_bus:phy_addr=dsa-0.0:01, irq=38)
RTL8366RB Gigabit Ethernet dsa-0.0:02: attached PHY driver [RTL8366RB Gigabit Ethernet] (mii_bus:phy_addr=dsa-0.0:02, irq=39)
RTL8366RB Gigabit Ethernet dsa-0.0:03: attached PHY driver [RTL8366RB Gigabit Ethernet] (mii_bus:phy_addr=dsa-0.0:03, irq=40)
RTL8366RB Gigabit Ethernet dsa-0.0:04: attached PHY driver [RTL8366RB Gigabit Ethernet] (mii_bus:phy_addr=dsa-0.0:04, irq=41)
realtek-smi 0.switch: adjust link on CPU port
gmac-gemini 60000000.ethernet eth0: connected to PHY "fixed-0:00"
Generic PHY fixed-0:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=fixed-0:00, irq=POLL)
phy_id=0x00000000, phy_mode=rgmii
gmac-gemini 60000000.ethernet: set GMAC0 and GMAC1 to MII/RGMII mode
gmac-gemini 60000000.ethernet eth0: connect to RGMII
gmac-gemini 60000000.ethernet eth0: opened
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
realtek-smi 0.switch: enable port 0
IPv6: ADDRCONF(NETDEV_UP): lan0: link is not ready
realtek-smi 0.switch lan0: Link is Down
realtek-smi 0.switch lan0: Link is Up - 1Gbps/Full - flow control rx/tx
IPv6: ADDRCONF(NETDEV_CHANGE): lan0: link becomes ready

cat /proc/interrupts
 36:          6  FTGPIO010  15 Level     RTL8366RB
 37:          3  RTL8366RB   0 Edge      dsa-0.0:00
 38:          0  RTL8366RB   1 Edge      dsa-0.0:01
 39:          2  RTL8366RB   2 Edge      dsa-0.0:02
 40:          2  RTL8366RB   3 Edge      dsa-0.0:03
 41:          0  RTL8366RB   4 Edge      dsa-0.0:04

Plugged some cables in/out. Hooray, no polling needed.

Linus Walleij (4):
  RFC: net/dsa: Allow DSA PHYs to define link IRQs
  RFC: net: phy: realtek: Support RTL8366RB variant
  RFC: net: dsa: Add bindings for Realtek SMI DSAs
  RFC: net: dsa: realtek-smi: Add Realtek SMI driver

 .../devicetree/bindings/net/dsa/realtek-smi.txt    |  104 ++
 drivers/net/dsa/Kconfig                            |   12 +
 drivers/net/dsa/Makefile                           |    2 +
 drivers/net/dsa/realtek-smi.c                      |  436 ++++++++
 drivers/net/dsa/realtek-smi.h                      |  145 +++
 drivers/net/dsa/rtl8366.c                          |  493 +++++++++
 drivers/net/dsa/rtl8366rb.c                        | 1103 ++++++++++++++++++++
 drivers/net/phy/realtek.c                          |   32 +
 net/dsa/slave.c                                    |    8 +
 9 files changed, 2335 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
 create mode 100644 drivers/net/dsa/realtek-smi.c
 create mode 100644 drivers/net/dsa/realtek-smi.h
 create mode 100644 drivers/net/dsa/rtl8366.c
 create mode 100644 drivers/net/dsa/rtl8366rb.c

-- 
2.13.6

^ permalink raw reply	[flat|nested] 32+ messages in thread

* [PATCH 1/4] RFC: net/dsa: Allow DSA PHYs to define link IRQs
  2017-11-05 23:19 [PATCH 0/4] RFC: Realtek 83xx SMI driver core Linus Walleij
@ 2017-11-05 23:19 ` Linus Walleij
  2017-11-05 23:19 ` [PATCH 2/4] RFC: net: phy: realtek: Support RTL8366RB variant Linus Walleij
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 32+ messages in thread
From: Linus Walleij @ 2017-11-05 23:19 UTC (permalink / raw)
  To: Andrew Lunn, Vivien Didelot, Florian Fainelli
  Cc: netdev, Linus Walleij, Antti Seppälä,
	Roman Yeryomin, Colin Leitner, Gabor Juhos

PHYs attached to DSAs may provide IRQs from GPIOs or other
interrupt controllers in the device tree. For these cases,
we need to go and grab the IRQ before registering the slave
so the PHY core can grab and enable this IRQ.

Cc: Antti Seppälä <a.seppala@gmail.com>
Cc: Roman Yeryomin <roman@advem.lv>
Cc: Colin Leitner <colin.leitner@googlemail.com>
Cc: Gabor Juhos <juhosg@openwrt.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 net/dsa/slave.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 2afa99506f8b..9909d7fe80b1 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -15,6 +15,7 @@
 #include <linux/phy_fixed.h>
 #include <linux/of_net.h>
 #include <linux/of_mdio.h>
+#include <linux/of_irq.h>
 #include <linux/mdio.h>
 #include <linux/list.h>
 #include <net/rtnetlink.h>
@@ -1119,6 +1120,13 @@ static int dsa_slave_phy_connect(struct dsa_slave_priv *p,
 		return -ENODEV;
 	}
 
+	/*
+	 * If the PHY has a link IRQ associated with it in the device tree,
+	 * then assign it so it can be claimed by the core.
+	 */
+	if (of_irq_count(p->dp->dn))
+		p->phy->irq = irq_of_parse_and_map(p->dp->dn, 0);
+
 	/* Use already configured phy mode */
 	if (p->phy_interface == PHY_INTERFACE_MODE_NA)
 		p->phy_interface = p->phy->interface;
-- 
2.13.6

^ permalink raw reply related	[flat|nested] 32+ messages in thread

* [PATCH 2/4] RFC: net: phy: realtek: Support RTL8366RB variant
  2017-11-05 23:19 [PATCH 0/4] RFC: Realtek 83xx SMI driver core Linus Walleij
  2017-11-05 23:19 ` [PATCH 1/4] RFC: net/dsa: Allow DSA PHYs to define link IRQs Linus Walleij
@ 2017-11-05 23:19 ` Linus Walleij
  2017-11-05 23:19 ` [PATCH 3/4] RFC: net: dsa: Add bindings for Realtek SMI DSAs Linus Walleij
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 32+ messages in thread
From: Linus Walleij @ 2017-11-05 23:19 UTC (permalink / raw)
  To: Andrew Lunn, Vivien Didelot, Florian Fainelli
  Cc: netdev, Linus Walleij, Antti Seppälä,
	Roman Yeryomin, Colin Leitner, Gabor Juhos

The RTL8366RB is an ASIC with five internal PHYs for
LAN0..LAN3 and WAN. The PHYs are spawn off the main
device so they can be handled in a distributed manner
by the Realtek PHY driver. All that is really needed
is the power save feature enablement and letting the
PHY driver core pick up the IRQ from the switch chip.

Cc: Antti Seppälä <a.seppala@gmail.com>
Cc: Roman Yeryomin <roman@advem.lv>
Cc: Colin Leitner <colin.leitner@googlemail.com>
Cc: Gabor Juhos <juhosg@openwrt.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/net/phy/realtek.c | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 9cbe645e3d89..2fb2eb7a32be 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -29,6 +29,9 @@
 #define RTL8211F_PAGE_SELECT	0x1f
 #define RTL8211F_TX_DELAY	0x100
 
+#define RTL8366RB_POWER_SAVE	0x21
+#define RTL8366RB_POWER_SAVE_ON 0x1000
+
 MODULE_DESCRIPTION("Realtek PHY driver");
 MODULE_AUTHOR("Johnson Leung");
 MODULE_LICENSE("GPL");
@@ -119,6 +122,22 @@ static int rtl8211f_config_init(struct phy_device *phydev)
 	return 0;
 }
 
+static int rtl8366rb_config_init(struct phy_device *phydev)
+{
+	int ret;
+	u16 reg;
+
+	ret = genphy_config_init(phydev);
+	if (ret < 0)
+		return ret;
+
+	reg = phy_read(phydev, RTL8366RB_POWER_SAVE);
+	reg |= RTL8366RB_POWER_SAVE_ON;
+	phy_write(phydev, RTL8366RB_POWER_SAVE, reg);
+
+	return 0;
+}
+
 static struct phy_driver realtek_drvs[] = {
 	{
 		.phy_id         = 0x00008201,
@@ -175,6 +194,18 @@ static struct phy_driver realtek_drvs[] = {
 		.config_intr	= &rtl8211f_config_intr,
 		.suspend	= genphy_suspend,
 		.resume		= genphy_resume,
+	}, {
+		/* The main part of this DSA is in drivers/net/dsa */
+		.phy_id		= 0x001cc961,
+		.name		= "RTL8366RB Gigabit Ethernet",
+		.phy_id_mask	= 0x001fffff,
+		.features	= PHY_GBIT_FEATURES,
+		.flags		= PHY_HAS_INTERRUPT,
+		.config_aneg	= &genphy_config_aneg,
+		.config_init	= &rtl8366rb_config_init,
+		.read_status	= &genphy_read_status,
+		.suspend	= genphy_suspend,
+		.resume		= genphy_resume,
 	},
 };
 
@@ -185,6 +216,7 @@ static struct mdio_device_id __maybe_unused realtek_tbl[] = {
 	{ 0x001cc914, 0x001fffff },
 	{ 0x001cc915, 0x001fffff },
 	{ 0x001cc916, 0x001fffff },
+	{ 0x001cc961, 0x001fffff },
 	{ }
 };
 
-- 
2.13.6

^ permalink raw reply related	[flat|nested] 32+ messages in thread

* [PATCH 3/4] RFC: net: dsa: Add bindings for Realtek SMI DSAs
  2017-11-05 23:19 [PATCH 0/4] RFC: Realtek 83xx SMI driver core Linus Walleij
  2017-11-05 23:19 ` [PATCH 1/4] RFC: net/dsa: Allow DSA PHYs to define link IRQs Linus Walleij
  2017-11-05 23:19 ` [PATCH 2/4] RFC: net: phy: realtek: Support RTL8366RB variant Linus Walleij
@ 2017-11-05 23:19 ` Linus Walleij
  2017-11-05 23:48   ` Andrew Lunn
  2017-11-05 23:19 ` [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver Linus Walleij
  2018-04-02 16:10 ` [PATCH 0/4] RFC: Realtek 83xx SMI driver core Carl-Daniel Hailfinger
  4 siblings, 1 reply; 32+ messages in thread
From: Linus Walleij @ 2017-11-05 23:19 UTC (permalink / raw)
  To: Andrew Lunn, Vivien Didelot, Florian Fainelli
  Cc: netdev, Linus Walleij, Antti Seppälä,
	Roman Yeryomin, Colin Leitner, Gabor Juhos, devicetree

The Realtek SMI family is a set of DSA chips that provide
switching in routers. This binding just follows the pattern
set by other switches but with the introduction of an embedded
irqchip to demux and handle the interrupts fired by the single
line from the chip.

This interrupt construction is similar to how we handle
interrupt controllers inside PCI bridges etc.

Cc: Antti Seppälä <a.seppala@gmail.com>
Cc: Roman Yeryomin <roman@advem.lv>
Cc: Colin Leitner <colin.leitner@googlemail.com>
Cc: Gabor Juhos <juhosg@openwrt.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 .../devicetree/bindings/net/dsa/realtek-smi.txt    | 104 +++++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/dsa/realtek-smi.txt

diff --git a/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt b/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
new file mode 100644
index 000000000000..95e96d49c0be
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
@@ -0,0 +1,104 @@
+Realtek SMI-based Switches
+==========================
+
+The SMI "Simple Management Interface" is a two-wire protocol using
+bit-banged GPIO that while it reuses the MDIO lines MCK and MDIO does
+not use the MDIO protocol. This binding defines how to specify the
+SMI-based Realtek devices.
+
+Required properties:
+
+- compatible: must be exactly one of:
+      "realtek,rtl8366"
+      "realtek,rtl8369"
+      "realtek,rtl8366rb"
+      "realtek,rtl8366s"
+      "realtek,rtl8367"
+      "realtek,rtl8367b"
+
+Required subnode:
+
+- interrupt-controller
+
+  This defines an interrupt controller with an IRQ line (typically
+  a GPIO) that will demultiplex and handle the interrupt from the single
+  interrupt line coming out of one of the SMI-based chips. It most
+  importantly provides link up/down interrupts to the PHY blocks inside
+  the ASIC.
+
+Required properties of interrupt-controller:
+
+- interrupt: parent interrupt, see interrupt-controller/interrupts.txt
+- interrupt-controller: see interrupt-controller/interrupts.txt
+- #address-cells: should be <0>
+- #interrupt-cells: should be <1>
+
+See net/dsa/dsa.txt for a list of additional required and optional properties
+and subnodes.
+
+
+Examples:
+
+switch {
+	compatible = "realtek,rtl8366rb";
+	reg = <0>;
+	/* 22 = MDIO (has input reads), 21 = MDC (clock, output only) */
+	mdc-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>;
+	mdio-gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>;
+	reset-gpios = <&gpio0 14 GPIO_ACTIVE_LOW>;
+
+	switch_intc: interrupt-controller {
+		/* GPIO 15 provides the interrupt */
+		interrupt-parent = <&gpio0>;
+		interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
+		interrupt-controller;
+		#address-cells = <0>;
+		#interrupt-cells = <1>;
+	};
+
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0>;
+		port@0 {
+			reg = <0>;
+			label = "lan0";
+			interrupt-parent = <&switch_intc>;
+			interrupts = <0>;
+		};
+		port@1 {
+			reg = <1>;
+			label = "lan1";
+			interrupt-parent = <&switch_intc>;
+			interrupts = <1>;
+		};
+		port@2 {
+			reg = <2>;
+			label = "lan2";
+			interrupt-parent = <&switch_intc>;
+			interrupts = <2>;
+		};
+		port@3 {
+			reg = <3>;
+			label = "lan3";
+			interrupt-parent = <&switch_intc>;
+			interrupts = <3>;
+		};
+		port@4 {
+			reg = <4>;
+			label = "wan";
+			interrupt-parent = <&switch_intc>;
+			interrupts = <4>;
+		};
+		phy0: port@5 {
+			reg = <5>;
+			label = "cpu";
+			ethernet = <&gmac0>;
+			phy-mode = "rgmii";
+			fixed-link {
+				speed = <1000>;
+				full-duplex;
+			};
+		};
+	};
+};
-- 
2.13.6

^ permalink raw reply related	[flat|nested] 32+ messages in thread

* [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver
  2017-11-05 23:19 [PATCH 0/4] RFC: Realtek 83xx SMI driver core Linus Walleij
                   ` (2 preceding siblings ...)
  2017-11-05 23:19 ` [PATCH 3/4] RFC: net: dsa: Add bindings for Realtek SMI DSAs Linus Walleij
@ 2017-11-05 23:19 ` Linus Walleij
  2017-11-05 23:59   ` Andrew Lunn
  2017-11-09 12:49   ` Roman Yeryomin
  2018-04-02 16:10 ` [PATCH 0/4] RFC: Realtek 83xx SMI driver core Carl-Daniel Hailfinger
  4 siblings, 2 replies; 32+ messages in thread
From: Linus Walleij @ 2017-11-05 23:19 UTC (permalink / raw)
  To: Andrew Lunn, Vivien Didelot, Florian Fainelli
  Cc: netdev, Linus Walleij, Antti Seppälä,
	Roman Yeryomin, Colin Leitner, Gabor Juhos

This adds a driver core for the Realtek SMI chips and a subdriver
for the RTL8366RB. I just added this chip simply because it is
all I can test.

The code is a massaged variant of the code that has been sitting
out-of-tree in OpenWRT for years in the absence of a proper switch
subsystem. I have tried to credit the original authors wherever
possible.

The main changes I've done from the OpenWRT code:
- Added a callback to set the MAC address.
- Added an IRQ chip inside the RTL8366RB switch to demux and
  handle the line state IRQs.
- Distributed the phy handling out to the PHY driver.
- Added some RTL8366RB code that was missing in the driver,
  such as setting up "green ethernet" with a funny jam table
  and forcing MAC5 (the CPU port) into 1 GBit.

Cc: Antti Seppälä <a.seppala@gmail.com>
Cc: Roman Yeryomin <roman@advem.lv>
Cc: Colin Leitner <colin.leitner@googlemail.com>
Cc: Gabor Juhos <juhosg@openwrt.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/net/dsa/Kconfig       |   12 +
 drivers/net/dsa/Makefile      |    2 +
 drivers/net/dsa/realtek-smi.c |  436 ++++++++++++++++
 drivers/net/dsa/realtek-smi.h |  145 ++++++
 drivers/net/dsa/rtl8366.c     |  493 ++++++++++++++++++
 drivers/net/dsa/rtl8366rb.c   | 1103 +++++++++++++++++++++++++++++++++++++++++
 6 files changed, 2191 insertions(+)
 create mode 100644 drivers/net/dsa/realtek-smi.c
 create mode 100644 drivers/net/dsa/realtek-smi.h
 create mode 100644 drivers/net/dsa/rtl8366.c
 create mode 100644 drivers/net/dsa/rtl8366rb.c

diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index 83a9bc892a3b..d25fa9a35ad3 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -52,6 +52,18 @@ config NET_DSA_QCA8K
 	  This enables support for the Qualcomm Atheros QCA8K Ethernet
 	  switch chips.
 
+config NET_DSA_RTK_SMI
+	tristate "Realtek SMI Ethernet switch family support"
+	depends on NET_DSA
+	# FIXME: select NET_DSA_TAG_RTK
+	select FIXED_PHY
+	select IRQ_DOMAIN
+	select REALTEK_PHY
+	select NET_DSA_TAG_TRAILER
+	---help---
+	  This enables support for the Realtek SMI-based switch
+	  chips, currently only RTL8366RB.
+
 config NET_DSA_SMSC_LAN9303
 	tristate
 	select NET_DSA_TAG_LAN9303
diff --git a/drivers/net/dsa/Makefile b/drivers/net/dsa/Makefile
index 4a5b5bd297ee..f660096cbad1 100644
--- a/drivers/net/dsa/Makefile
+++ b/drivers/net/dsa/Makefile
@@ -4,6 +4,8 @@ obj-$(CONFIG_NET_DSA_LOOP)	+= dsa_loop.o dsa_loop_bdinfo.o
 obj-$(CONFIG_NET_DSA_MT7530)	+= mt7530.o
 obj-$(CONFIG_NET_DSA_MV88E6060) += mv88e6060.o
 obj-$(CONFIG_NET_DSA_QCA8K)	+= qca8k.o
+obj-$(CONFIG_NET_DSA_RTK_SMI)	+= realtek.o
+realtek-objs			:= realtek-smi.o rtl8366.o rtl8366rb.o
 obj-$(CONFIG_NET_DSA_SMSC_LAN9303) += lan9303-core.o
 obj-$(CONFIG_NET_DSA_SMSC_LAN9303_I2C) += lan9303_i2c.o
 obj-$(CONFIG_NET_DSA_SMSC_LAN9303_MDIO) += lan9303_mdio.o
diff --git a/drivers/net/dsa/realtek-smi.c b/drivers/net/dsa/realtek-smi.c
new file mode 100644
index 000000000000..de37b9a776fa
--- /dev/null
+++ b/drivers/net/dsa/realtek-smi.c
@@ -0,0 +1,436 @@
+/*
+ * Realtek Simple Management Interface (SMI) driver
+ * It can be discussed how "simple" this interface is.
+ *
+ * The SMI protocol piggy-backs the MDIO MDC and MDIO signals levels
+ * but the protocol is not MDIO at all. Instead it is a Realtek
+ * pecularity that need to bit-bang the lines in a special way to
+ * communicate with the switch.
+ *
+ * ASICs we intend to support with this driver:
+ *
+ * RTL8366   - The original version, apparently
+ * RTL8369   - Similar enough to have the same datsheet as RTL8366
+ * RTL8366RB - Probably reads out "RTL8366 revision B", has a quite
+ *             different register layout from the other two
+ * RTL8366S  - Is this "RTL8366 super"?
+ * RTL8367   - Has an OpenWRT driver as well
+ * RTL8368S  - Seems to be an alternative name for RTL8366RB
+ * RTL8370   - Also uses SMI
+ *
+ * Copyright (C) 2017 Linus Walleij <linus.walleij@linaro.org>
+ * Copyright (C) 2010 Antti Seppälä <a.seppala@gmail.com>
+ * Copyright (C) 2010 Roman Yeryomin <roman@advem.lv>
+ * Copyright (C) 2011 Colin Leitner <colin.leitner@googlemail.com>
+ * Copyright (C) 2009-2010 Gabor Juhos <juhosg@openwrt.org>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/spinlock.h>
+#include <linux/skbuff.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/bitops.h>
+#include <linux/if_bridge.h>
+
+#include "realtek-smi.h"
+
+#define REALTEK_SMI_ACK_RETRY_COUNT		5
+#define REALTEK_SMI_HW_STOP_DELAY		25	/* msecs */
+#define REALTEK_SMI_HW_START_DELAY		100	/* msecs */
+
+static inline void realtek_smi_clk_delay(struct realtek_smi *smi)
+{
+	ndelay(smi->clk_delay);
+}
+
+static void realtek_smi_start(struct realtek_smi *smi)
+{
+	/*
+	 * Set GPIO pins to output mode, with initial state:
+	 * SCK = 0, SDA = 1
+	 */
+	gpiod_direction_output(smi->mdc, 0);
+	gpiod_direction_output(smi->mdio, 1);
+	realtek_smi_clk_delay(smi);
+
+	/* CLK 1: 0 -> 1, 1 -> 0 */
+	gpiod_set_value(smi->mdc, 1);
+	realtek_smi_clk_delay(smi);
+	gpiod_set_value(smi->mdc, 0);
+	realtek_smi_clk_delay(smi);
+
+	/* CLK 2: */
+	gpiod_set_value(smi->mdc, 1);
+	realtek_smi_clk_delay(smi);
+	gpiod_set_value(smi->mdio, 0);
+	realtek_smi_clk_delay(smi);
+	gpiod_set_value(smi->mdc, 0);
+	realtek_smi_clk_delay(smi);
+	gpiod_set_value(smi->mdio, 1);
+}
+
+static void realtek_smi_stop(struct realtek_smi *smi)
+{
+	realtek_smi_clk_delay(smi);
+	gpiod_set_value(smi->mdio, 0);
+	gpiod_set_value(smi->mdc, 1);
+	realtek_smi_clk_delay(smi);
+	gpiod_set_value(smi->mdio, 1);
+	realtek_smi_clk_delay(smi);
+	gpiod_set_value(smi->mdc, 1);
+	realtek_smi_clk_delay(smi);
+	gpiod_set_value(smi->mdc, 0);
+	realtek_smi_clk_delay(smi);
+	gpiod_set_value(smi->mdc, 1);
+
+	/* add a click */
+	realtek_smi_clk_delay(smi);
+	gpiod_set_value(smi->mdc, 0);
+	realtek_smi_clk_delay(smi);
+	gpiod_set_value(smi->mdc, 1);
+
+	/* set GPIO pins to input mode */
+	gpiod_direction_input(smi->mdio);
+	gpiod_direction_input(smi->mdc);
+}
+
+static void realtek_smi_write_bits(struct realtek_smi *smi, u32 data, u32 len)
+{
+	for (; len > 0; len--) {
+		realtek_smi_clk_delay(smi);
+
+		/* prepare data */
+		gpiod_set_value(smi->mdio, !!(data & ( 1 << (len - 1))));
+		realtek_smi_clk_delay(smi);
+
+		/* clocking */
+		gpiod_set_value(smi->mdc, 1);
+		realtek_smi_clk_delay(smi);
+		gpiod_set_value(smi->mdc, 0);
+	}
+}
+
+static void realtek_smi_read_bits(struct realtek_smi *smi, u32 len, u32 *data)
+{
+	gpiod_direction_input(smi->mdio);
+
+	for (*data = 0; len > 0; len--) {
+		u32 u;
+
+		realtek_smi_clk_delay(smi);
+
+		/* clocking */
+		gpiod_set_value(smi->mdc, 1);
+		realtek_smi_clk_delay(smi);
+		u = !!gpiod_get_value(smi->mdio);
+		gpiod_set_value(smi->mdc, 0);
+
+		*data |= (u << (len - 1));
+	}
+
+	gpiod_direction_output(smi->mdio, 0);
+}
+
+static int realtek_smi_wait_for_ack(struct realtek_smi *smi)
+{
+	int retry_cnt;
+
+	retry_cnt = 0;
+	do {
+		u32 ack;
+
+		realtek_smi_read_bits(smi, 1, &ack);
+		if (ack == 0)
+			break;
+
+		if (++retry_cnt > REALTEK_SMI_ACK_RETRY_COUNT) {
+			dev_err(smi->dev, "ACK timeout\n");
+			return -ETIMEDOUT;
+		}
+	} while (1);
+
+	return 0;
+}
+
+static int realtek_smi_write_byte(struct realtek_smi *smi, u8 data)
+{
+	realtek_smi_write_bits(smi, data, 8);
+	return realtek_smi_wait_for_ack(smi);
+}
+
+static int realtek_smi_write_byte_noack(struct realtek_smi *smi, u8 data)
+{
+	realtek_smi_write_bits(smi, data, 8);
+	return 0;
+}
+
+static int realtek_smi_read_byte0(struct realtek_smi *smi, u8 *data)
+{
+	u32 t;
+
+	/* read data */
+	realtek_smi_read_bits(smi, 8, &t);
+	*data = (t & 0xff);
+
+	/* send an ACK */
+	realtek_smi_write_bits(smi, 0x00, 1);
+
+	return 0;
+}
+
+static int realtek_smi_read_byte1(struct realtek_smi *smi, u8 *data)
+{
+	u32 t;
+
+	/* read data */
+	realtek_smi_read_bits(smi, 8, &t);
+	*data = (t & 0xff);
+
+	/* send an ACK */
+	realtek_smi_write_bits(smi, 0x01, 1);
+
+	return 0;
+}
+
+static int realtek_smi_read_reg(struct realtek_smi *smi, u32 addr, u32 *data)
+{
+	unsigned long flags;
+	u8 lo = 0;
+	u8 hi = 0;
+	int ret;
+
+	spin_lock_irqsave(&smi->lock, flags);
+
+	realtek_smi_start(smi);
+
+	/* send READ command */
+	ret = realtek_smi_write_byte(smi, smi->cmd_read);
+	if (ret)
+		goto out;
+
+	/* set ADDR[7:0] */
+	ret = realtek_smi_write_byte(smi, addr & 0xff);
+	if (ret)
+		goto out;
+
+	/* set ADDR[15:8] */
+	ret = realtek_smi_write_byte(smi, addr >> 8);
+	if (ret)
+		goto out;
+
+	/* read DATA[7:0] */
+	realtek_smi_read_byte0(smi, &lo);
+	/* read DATA[15:8] */
+	realtek_smi_read_byte1(smi, &hi);
+
+	*data = ((u32) lo) | (((u32) hi) << 8);
+
+	ret = 0;
+
+ out:
+	realtek_smi_stop(smi);
+	spin_unlock_irqrestore(&smi->lock, flags);
+
+	return ret;
+}
+
+static int realtek_smi_write_reg(struct realtek_smi *smi,
+				 u32 addr, u32 data, bool ack)
+{
+	unsigned long flags;
+	int ret;
+
+	spin_lock_irqsave(&smi->lock, flags);
+
+	realtek_smi_start(smi);
+
+	/* send WRITE command */
+	ret = realtek_smi_write_byte(smi, smi->cmd_write);
+	if (ret)
+		goto out;
+
+	/* set ADDR[7:0] */
+	ret = realtek_smi_write_byte(smi, addr & 0xff);
+	if (ret)
+		goto out;
+
+	/* set ADDR[15:8] */
+	ret = realtek_smi_write_byte(smi, addr >> 8);
+	if (ret)
+		goto out;
+
+	/* write DATA[7:0] */
+	ret = realtek_smi_write_byte(smi, data & 0xff);
+	if (ret)
+		goto out;
+
+	/* write DATA[15:8] */
+	if (ack)
+		ret = realtek_smi_write_byte(smi, data >> 8);
+	else
+		ret = realtek_smi_write_byte_noack(smi, data >> 8);
+	if (ret)
+		goto out;
+
+	ret = 0;
+
+ out:
+	realtek_smi_stop(smi);
+	spin_unlock_irqrestore(&smi->lock, flags);
+
+	return ret;
+}
+
+/*
+ * There is one single case when we need to use this accessor and that
+ * is when issueing soft reset. Since the device reset as soon as we write
+ * that bit, no ACK will come back for natural reasons.
+ */
+int realtek_smi_write_reg_noack(struct realtek_smi *smi, u32 addr,
+				u32 data)
+{
+	return realtek_smi_write_reg(smi, addr, data, false);
+}
+EXPORT_SYMBOL_GPL(realtek_smi_write_reg_noack);
+
+/* Regmap accessors */
+
+static int realtek_smi_write(void *ctx, u32 reg, u32 val)
+{
+	struct realtek_smi *smi = ctx;
+
+	return realtek_smi_write_reg(smi, reg, val, true);
+}
+
+static int realtek_smi_read(void *ctx, u32 reg, u32 *val)
+{
+	struct realtek_smi *smi = ctx;
+
+	return realtek_smi_read_reg(smi, reg, val);
+}
+
+static const struct regmap_config realtek_smi_mdio_regmap_config = {
+	.reg_bits = 10, /* A4..A0 R4..R0 */
+	.val_bits = 16,
+	.reg_stride = 1,
+	/* phy regs are at 0x8000 */
+	.max_register = 0xffff,
+	.reg_format_endian = REGMAP_ENDIAN_LITTLE,
+	.reg_read = realtek_smi_read,
+	.reg_write = realtek_smi_write,
+	.cache_type = REGCACHE_NONE,
+};
+
+static int realtek_smi_probe(struct platform_device *pdev)
+{
+	struct realtek_smi *smi;
+	struct device *dev = &pdev->dev;
+	const struct realtek_smi_variant *var = of_device_get_match_data(dev);
+	int ret;
+
+	smi = devm_kzalloc(dev, sizeof(*smi), GFP_KERNEL);
+	if (!smi)
+		return -ENOMEM;
+	smi->map = devm_regmap_init(dev, NULL, smi,
+				    &realtek_smi_mdio_regmap_config);
+	if (IS_ERR(smi->map)) {
+		ret = PTR_ERR(smi->map);
+		dev_err(dev, "regmap init failed: %d\n", ret);
+		return ret;
+	}
+
+	/* link forward and backward */
+	smi->dev = dev;
+	smi->clk_delay = var->clk_delay;
+	smi->cmd_read  = var->cmd_read;
+	smi->cmd_write = var->cmd_write;
+	smi->ops = var->ops;
+
+	dev_set_drvdata(dev, smi);
+	spin_lock_init(&smi->lock);
+
+	/* TODO: if power is software controlled, set up any regulators here */
+
+	/* Assert then deassert RESET */
+	smi->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
+	if (IS_ERR(smi->reset)) {
+		dev_err(dev, "failed to get RESET GPIO\n");
+		return PTR_ERR(smi->reset);
+	}
+	msleep(REALTEK_SMI_HW_STOP_DELAY);
+	gpiod_set_value(smi->reset, 0);
+	msleep(REALTEK_SMI_HW_START_DELAY);
+	dev_info(dev, "deasserted RESET\n");
+
+	/* Fetch MDIO pins */
+	smi->mdc = devm_gpiod_get_optional(dev, "mdc", GPIOD_OUT_LOW);
+	if (IS_ERR(smi->mdc))
+		return PTR_ERR(smi->mdc);
+	smi->mdio = devm_gpiod_get_optional(dev, "mdio", GPIOD_OUT_LOW);
+	if (IS_ERR(smi->mdio))
+		return PTR_ERR(smi->mdio);
+
+	ret = smi->ops->detect(smi);
+	if (ret) {
+		dev_err(dev, "unable to detect switch\n");
+		return ret;
+	}
+
+	smi->ds = dsa_switch_alloc(dev, smi->num_ports);
+	if (!smi->ds)
+		return -ENOMEM;
+	smi->ds->priv = smi;
+	smi->ds->ops = var->ds_ops;
+
+	ret = dsa_register_switch(smi->ds);
+	if (ret) {
+		dev_err(dev, "unable to register switch ret = %d\n", ret);
+		return ret;
+	}
+	return 0;
+}
+
+static int realtek_smi_remove(struct platform_device *pdev)
+{
+	struct realtek_smi *smi = dev_get_drvdata(&pdev->dev);
+
+	dsa_unregister_switch(smi->ds);
+	gpiod_set_value(smi->reset, 1);
+
+	return 0;
+}
+
+static const struct of_device_id realtek_smi_of_match[] = {
+	{
+		.compatible = "realtek,rtl8366rb",
+		.data = &rtl8366rb_variant,
+	},
+	{
+		/* FIXME: add support for RTL8366S and more */
+		.compatible = "realtek,rtl8366s",
+		.data = NULL,
+	},
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, realtek_smi_of_match);
+
+static struct platform_driver realtek_smi_driver = {
+	.driver = {
+		.name = "realtek-smi",
+		.of_match_table = of_match_ptr(realtek_smi_of_match),
+	},
+	.probe  = realtek_smi_probe,
+	.remove = realtek_smi_remove,
+};
+module_platform_driver(realtek_smi_driver);
diff --git a/drivers/net/dsa/realtek-smi.h b/drivers/net/dsa/realtek-smi.h
new file mode 100644
index 000000000000..682895e932ab
--- /dev/null
+++ b/drivers/net/dsa/realtek-smi.h
@@ -0,0 +1,145 @@
+/*
+ * Realtek SMI interface driver defines
+ *
+ * Copyright (C) 2017 Linus Walleij <linus.walleij@linaro.org>
+ * Copyright (C) 2009-2010 Gabor Juhos <juhosg@openwrt.org>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#ifndef _REALTEK_SMI_H
+#define _REALTEK_SMI_H
+
+#include <linux/phy.h>
+#include <linux/platform_device.h>
+#include <linux/gpio/consumer.h>
+#include <net/dsa.h>
+
+struct realtek_smi_ops;
+struct dentry;
+struct inode;
+struct file;
+
+struct rtl8366_mib_counter {
+	unsigned	base;
+	unsigned	offset;
+	unsigned	length;
+	const char	*name;
+};
+
+struct rtl8366_vlan_mc {
+	u16	vid;
+	u16	untag;
+	u16	member;
+	u8	fid;
+	u8	priority;
+};
+
+struct rtl8366_vlan_4k {
+	u16	vid;
+	u16	untag;
+	u16	member;
+	u8	fid;
+};
+
+struct realtek_smi {
+	struct device		*dev;
+	struct gpio_desc	*reset;
+	struct gpio_desc	*mdc;
+	struct gpio_desc	*mdio;
+	struct regmap		*map;
+	unsigned int		clk_delay;
+	u8			cmd_read;
+	u8			cmd_write;
+	spinlock_t		lock;
+	struct dsa_switch	*ds;
+	struct irq_domain	*irqdomain;
+
+	unsigned int		cpu_port;
+	unsigned int		num_ports;
+	unsigned int		num_vlan_mc;
+	unsigned int		num_mib_counters;
+	struct rtl8366_mib_counter *mib_counters;
+
+	const struct realtek_smi_ops *ops;
+
+	int			vlan_enabled;
+	int			vlan4k_enabled;
+
+	char			buf[4096];
+#ifdef CONFIG_RTL8366_SMI_DEBUG_FS
+	struct dentry           *debugfs_root;
+	u8			dbg_vlan_4k_page;
+#endif
+};
+
+/**
+ * struct realtek_smi_ops - vtable for the per-SMI-chiptype operations
+ * @detect: detects the chiptype
+ */
+struct realtek_smi_ops {
+	int	(*detect)(struct realtek_smi *smi);
+	int	(*reset_chip)(struct realtek_smi *smi);
+	int	(*setup)(struct realtek_smi *smi);
+	void	(*cleanup)(struct realtek_smi *smi);
+	int	(*get_mib_counter)(struct realtek_smi *smi,
+				   int port,
+				   struct rtl8366_mib_counter *mib,
+				   u64 *mibvalue);
+	int	(*get_vlan_mc)(struct realtek_smi *smi, u32 index,
+			       struct rtl8366_vlan_mc *vlanmc);
+	int	(*set_vlan_mc)(struct realtek_smi *smi, u32 index,
+			       const struct rtl8366_vlan_mc *vlanmc);
+	int	(*get_vlan_4k)(struct realtek_smi *smi, u32 vid,
+			       struct rtl8366_vlan_4k *vlan4k);
+	int	(*set_vlan_4k)(struct realtek_smi *smi,
+			       const struct rtl8366_vlan_4k *vlan4k);
+	int	(*get_mc_index)(struct realtek_smi *smi, int port, int *val);
+	int	(*set_mc_index)(struct realtek_smi *smi, int port, int index);
+	bool	(*is_vlan_valid)(struct realtek_smi *smi, unsigned vlan);
+	int	(*enable_vlan)(struct realtek_smi *smi, bool enable);
+	int	(*enable_vlan4k)(struct realtek_smi *smi, bool enable);
+	int	(*enable_port)(struct realtek_smi *smi, int port, bool enable);
+};
+
+struct realtek_smi_variant {
+	const struct dsa_switch_ops *ds_ops;
+	const struct realtek_smi_ops *ops;
+	unsigned int clk_delay;
+	u8 cmd_read;
+	u8 cmd_write;
+};
+
+/* SMI core calls */
+int realtek_smi_write_reg_noack(struct realtek_smi *smi, u32 addr,
+				u32 data);
+
+/* RTL8366 library helpers */
+int rtl8366_mc_is_used(struct realtek_smi *smi, int mc_index, int *used);
+int rtl8366_set_vlan(struct realtek_smi *smi, int vid, u32 member,
+		     u32 untag, u32 fid);
+int rtl8366_get_pvid(struct realtek_smi *smi, int port, int *val);
+int rtl8366_set_pvid(struct realtek_smi *smi, unsigned port,
+		     unsigned vid);
+int rtl8366_enable_vlan4k(struct realtek_smi *smi, bool enable);
+int rtl8366_enable_vlan(struct realtek_smi *smi, bool enable);
+int rtl8366_reset_vlan(struct realtek_smi *smi);
+int rtl8366_init_vlan(struct realtek_smi *smi);
+int rtl8366_vlan_filtering(struct dsa_switch *ds, int port, bool vlan_filtering);
+int rtl8366_vlan_prepare(struct dsa_switch *ds, int port,
+			 const struct switchdev_obj_port_vlan *vlan,
+			 struct switchdev_trans *trans);
+void rtl8366_vlan_add(struct dsa_switch *ds, int port,
+		      const struct switchdev_obj_port_vlan *vlan,
+		      struct switchdev_trans *trans);
+int rtl8366_vlan_del(struct dsa_switch *ds, int port,
+		     const struct switchdev_obj_port_vlan *vlan);
+void rtl8366_get_strings(struct dsa_switch *ds, int port, uint8_t *data);
+int rtl8366_get_sset_count(struct dsa_switch *ds);
+void rtl8366_get_ethtool_stats(struct dsa_switch *ds, int port, uint64_t *data);
+
+extern const struct realtek_smi_variant rtl8366rb_variant;
+
+#endif /*  _REALTEK_SMI_H */
diff --git a/drivers/net/dsa/rtl8366.c b/drivers/net/dsa/rtl8366.c
new file mode 100644
index 000000000000..bb50cf9e2074
--- /dev/null
+++ b/drivers/net/dsa/rtl8366.c
@@ -0,0 +1,493 @@
+/*
+ * Realtek SMI library helpers for the RTL8366x variants
+ * RTL8366RB and RTL8366S
+ *
+ * Copyright (C) 2017 Linus Walleij <linus.walleij@linaro.org>
+ * Copyright (C) 2009-2010 Gabor Juhos <juhosg@openwrt.org>
+ * Copyright (C) 2010 Antti Seppälä <a.seppala@gmail.com>
+ * Copyright (C) 2010 Roman Yeryomin <roman@advem.lv>
+ * Copyright (C) 2011 Colin Leitner <colin.leitner@googlemail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include <net/dsa.h>
+#include <linux/if_bridge.h>
+#include "realtek-smi.h"
+
+int rtl8366_mc_is_used(struct realtek_smi *smi, int mc_index, int *used)
+{
+	int ret;
+	int i;
+
+	*used = 0;
+	for (i = 0; i < smi->num_ports; i++) {
+		int index = 0;
+
+		ret = smi->ops->get_mc_index(smi, i, &index);
+		if (ret)
+			return ret;
+
+		if (mc_index == index) {
+			*used = 1;
+			break;
+		}
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(rtl8366_mc_is_used);
+
+int rtl8366_set_vlan(struct realtek_smi *smi, int vid, u32 member,
+		     u32 untag, u32 fid)
+{
+	struct rtl8366_vlan_4k vlan4k;
+	int ret;
+	int i;
+
+	/* Update the 4K table */
+	ret = smi->ops->get_vlan_4k(smi, vid, &vlan4k);
+	if (ret)
+		return ret;
+
+	vlan4k.member = member;
+	vlan4k.untag = untag;
+	vlan4k.fid = fid;
+	ret = smi->ops->set_vlan_4k(smi, &vlan4k);
+	if (ret)
+		return ret;
+
+	/* Try to find an existing MC entry for this VID */
+	for (i = 0; i < smi->num_vlan_mc; i++) {
+		struct rtl8366_vlan_mc vlanmc;
+
+		ret = smi->ops->get_vlan_mc(smi, i, &vlanmc);
+		if (ret)
+			return ret;
+
+		if (vid == vlanmc.vid) {
+			/* update the MC entry */
+			vlanmc.member = member;
+			vlanmc.untag = untag;
+			vlanmc.fid = fid;
+
+			ret = smi->ops->set_vlan_mc(smi, i, &vlanmc);
+			break;
+		}
+	}
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(rtl8366_set_vlan);
+
+int rtl8366_get_pvid(struct realtek_smi *smi, int port, int *val)
+{
+	struct rtl8366_vlan_mc vlanmc;
+	int ret;
+	int index;
+
+	ret = smi->ops->get_mc_index(smi, port, &index);
+	if (ret)
+		return ret;
+
+	ret = smi->ops->get_vlan_mc(smi, index, &vlanmc);
+	if (ret)
+		return ret;
+
+	*val = vlanmc.vid;
+	return 0;
+}
+EXPORT_SYMBOL_GPL(rtl8366_get_pvid);
+
+int rtl8366_set_pvid(struct realtek_smi *smi, unsigned port,
+		     unsigned vid)
+{
+	struct rtl8366_vlan_mc vlanmc;
+	struct rtl8366_vlan_4k vlan4k;
+	int ret;
+	int i;
+
+	/* Try to find an existing MC entry for this VID */
+	for (i = 0; i < smi->num_vlan_mc; i++) {
+		ret = smi->ops->get_vlan_mc(smi, i, &vlanmc);
+		if (ret)
+			return ret;
+
+		if (vid == vlanmc.vid) {
+			ret = smi->ops->set_vlan_mc(smi, i, &vlanmc);
+			if (ret)
+				return ret;
+
+			ret = smi->ops->set_mc_index(smi, port, i);
+			return ret;
+		}
+	}
+
+	/* We have no MC entry for this VID, try to find an empty one */
+	for (i = 0; i < smi->num_vlan_mc; i++) {
+		ret = smi->ops->get_vlan_mc(smi, i, &vlanmc);
+		if (ret)
+			return ret;
+
+		if (vlanmc.vid == 0 && vlanmc.member == 0) {
+			/* Update the entry from the 4K table */
+			ret = smi->ops->get_vlan_4k(smi, vid, &vlan4k);
+			if (ret)
+				return ret;
+
+			vlanmc.vid = vid;
+			vlanmc.member = vlan4k.member;
+			vlanmc.untag = vlan4k.untag;
+			vlanmc.fid = vlan4k.fid;
+			ret = smi->ops->set_vlan_mc(smi, i, &vlanmc);
+			if (ret)
+				return ret;
+
+			ret = smi->ops->set_mc_index(smi, port, i);
+			return ret;
+		}
+	}
+
+	/* MC table is full, try to find an unused entry and replace it */
+	for (i = 0; i < smi->num_vlan_mc; i++) {
+		int used;
+
+		ret = rtl8366_mc_is_used(smi, i, &used);
+		if (ret)
+			return ret;
+
+		if (!used) {
+			/* Update the entry from the 4K table */
+			ret = smi->ops->get_vlan_4k(smi, vid, &vlan4k);
+			if (ret)
+				return ret;
+
+			vlanmc.vid = vid;
+			vlanmc.member = vlan4k.member;
+			vlanmc.untag = vlan4k.untag;
+			vlanmc.fid = vlan4k.fid;
+			ret = smi->ops->set_vlan_mc(smi, i, &vlanmc);
+			if (ret)
+				return ret;
+
+			ret = smi->ops->set_mc_index(smi, port, i);
+			return ret;
+		}
+	}
+
+	dev_err(smi->dev,
+		"all VLAN member configurations are in use\n");
+
+	return -ENOSPC;
+}
+EXPORT_SYMBOL_GPL(rtl8366_set_pvid);
+
+int rtl8366_enable_vlan4k(struct realtek_smi *smi, bool enable)
+{
+	int ret;
+
+	if (enable) {
+		ret = smi->ops->enable_vlan(smi, true);
+		if (ret)
+			return ret;
+
+		smi->vlan_enabled = true;
+	}
+
+	ret = smi->ops->enable_vlan4k(smi, enable);
+	if (ret)
+		return ret;
+
+	smi->vlan4k_enabled = enable;
+	return 0;
+}
+EXPORT_SYMBOL_GPL(rtl8366_enable_vlan4k);
+
+int rtl8366_enable_vlan(struct realtek_smi *smi, bool enable)
+{
+	int ret;
+
+	ret = smi->ops->enable_vlan(smi, true);
+	if (ret)
+		return ret;
+
+	smi->vlan_enabled = enable;
+
+	if (!enable) {
+		smi->vlan4k_enabled = false;
+		ret = smi->ops->enable_vlan4k(smi, false);
+	}
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(rtl8366_enable_vlan);
+
+int rtl8366_reset_vlan(struct realtek_smi *smi)
+{
+	struct rtl8366_vlan_mc vlanmc;
+	int ret;
+	int i;
+
+	rtl8366_enable_vlan(smi, false);
+	rtl8366_enable_vlan4k(smi, false);
+
+	/* clear VLAN member configurations */
+	vlanmc.vid = 0;
+	vlanmc.priority = 0;
+	vlanmc.member = 0;
+	vlanmc.untag = 0;
+	vlanmc.fid = 0;
+	for (i = 0; i < smi->num_vlan_mc; i++) {
+		ret = smi->ops->set_vlan_mc(smi, i, &vlanmc);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(rtl8366_reset_vlan);
+
+int rtl8366_init_vlan(struct realtek_smi *smi)
+{
+	int port;
+	int ret;
+
+	ret = rtl8366_reset_vlan(smi);
+	if (ret)
+		return ret;
+
+	for (port = 0; port < smi->num_ports; port++) {
+		u32 mask;
+
+		if (port == smi->cpu_port)
+			mask = (1 << smi->num_ports) - 1;
+		else
+			mask = (1 << port) | (1 << smi->cpu_port);
+
+		ret = rtl8366_set_vlan(smi, (port + 1), mask, mask, 0);
+		if (ret)
+			return ret;
+
+		ret = rtl8366_set_pvid(smi, port, (port + 1));
+		if (ret)
+			return ret;
+	}
+
+	return rtl8366_enable_vlan(smi, true);
+}
+EXPORT_SYMBOL_GPL(rtl8366_init_vlan);
+
+int rtl8366_vlan_filtering(struct dsa_switch *ds, int port, bool vlan_filtering)
+{
+	struct realtek_smi *smi = ds->priv;
+	struct rtl8366_vlan_4k vlan4k;
+	int ret;
+
+	if (!smi->ops->is_vlan_valid(smi, port))
+		return -EINVAL;
+
+	dev_info(smi->dev, "%s filtering on port %d\n",
+		 vlan_filtering ? "enable" : "disable",
+		 port);
+
+	/*
+	 * FIXME:
+	 * The hardware support filter ID (FID) 0..7, I have no clue how to
+	 * support this in the driver when the callback only says on/off.
+	 */
+	ret = smi->ops->get_vlan_4k(smi, port, &vlan4k);
+	if (ret)
+		return ret;
+
+	/* Just set the filter to FID 1 for now then */
+	ret = rtl8366_set_vlan(smi, port,
+			       vlan4k.member,
+			       vlan4k.untag,
+			       1);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(rtl8366_vlan_filtering);
+
+int rtl8366_vlan_prepare(struct dsa_switch *ds, int port,
+			 const struct switchdev_obj_port_vlan *vlan,
+			 struct switchdev_trans *trans)
+{
+	struct realtek_smi *smi = ds->priv;
+	int ret;
+
+	if (!smi->ops->is_vlan_valid(smi, port))
+		return -EINVAL;
+
+	dev_info(smi->dev, "prepare VLANs %04x..%04x\n",
+		 vlan->vid_begin, vlan->vid_end);
+
+	/*
+	 * FIXME: what's with this 4k business?
+	 * Just rtl8366_enable_vlan() seems inconclusive.
+	 */
+
+	/* Enable VLAN in the hardware */
+	ret = rtl8366_enable_vlan4k(smi, true);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(rtl8366_vlan_prepare);
+
+void rtl8366_vlan_add(struct dsa_switch *ds, int port,
+		      const struct switchdev_obj_port_vlan *vlan,
+		      struct switchdev_trans *trans)
+{
+	struct realtek_smi *smi = ds->priv;
+	bool untagged = vlan->flags & BRIDGE_VLAN_INFO_UNTAGGED;
+	bool pvid = vlan->flags & BRIDGE_VLAN_INFO_PVID;
+	u32 member = 0;
+	u32 untag = 0;
+	u16 vid;
+	int ret;
+
+	if (!smi->ops->is_vlan_valid(smi, port))
+		return;
+
+	dev_info(smi->dev, "add VLAN on port %d, %s, %s\n",
+		 port,
+		 untagged ? "untagged" : "tagged",
+		 pvid ? " PVID" : "no PVID");
+
+	if (dsa_is_dsa_port(ds, port) || dsa_is_cpu_port(ds, port)) {
+		dev_err(smi->dev, "port is DSA or CPU port\n");
+	}
+
+	for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) {
+		int pvid_val = 0;
+
+		dev_info(smi->dev, "add VLAN %04x\n", vid);
+		member |= BIT(port);
+
+		if (untagged)
+			untag |= BIT(port);
+
+		/*
+		 * To ensure that we have a valid MC entry for this VLAN,
+		 * initialize the port VLAN ID here.
+		 */
+		ret = rtl8366_get_pvid(smi, port, &pvid_val);
+		if (ret < 0) {
+			dev_err(smi->dev, "could not lookup PVID for port %d\n",
+				port);
+			return;
+		}
+		if (pvid_val == 0) {
+			ret = rtl8366_set_pvid(smi, port, vid);
+			if (ret < 0)
+				return;
+		}
+	}
+
+	ret = rtl8366_set_vlan(smi, port, member, untag, 0);
+	if (ret)
+		dev_err(smi->dev,
+			"failed to set up VLAN %04x",
+			vid);
+}
+EXPORT_SYMBOL_GPL(rtl8366_vlan_add);
+
+int rtl8366_vlan_del(struct dsa_switch *ds, int port,
+		     const struct switchdev_obj_port_vlan *vlan)
+{
+	struct realtek_smi *smi = ds->priv;
+	u16 vid;
+	int ret;
+
+	dev_info(smi->dev, "del VLAN on port %d\n", port);
+
+	for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) {
+		int i;
+
+		dev_info(smi->dev, "del VLAN %04x\n", vid);
+
+		for (i = 0; i < smi->num_vlan_mc; i++) {
+			struct rtl8366_vlan_mc vlanmc;
+
+			ret = smi->ops->get_vlan_mc(smi, i, &vlanmc);
+			if (ret)
+				return ret;
+
+			if (vid == vlanmc.vid) {
+				/* clear VLAN member configurations */
+				vlanmc.vid = 0;
+				vlanmc.priority = 0;
+				vlanmc.member = 0;
+				vlanmc.untag = 0;
+				vlanmc.fid = 0;
+
+				ret = smi->ops->set_vlan_mc(smi, i, &vlanmc);
+				if (ret) {
+					dev_err(smi->dev,
+						"failed to remove VLAN %04x\n",
+						vid);
+					return ret;
+				}
+				break;
+			}
+		}
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(rtl8366_vlan_del);
+
+void rtl8366_get_strings(struct dsa_switch *ds, int port, uint8_t *data)
+{
+	struct realtek_smi *smi = ds->priv;
+	struct rtl8366_mib_counter *mib;
+	int i;
+
+	if (port >= smi->num_ports)
+		return;
+
+	for (i = 0; i < smi->num_mib_counters; i++) {
+		mib = &smi->mib_counters[i];
+		memcpy(data + i * ETH_GSTRING_LEN,
+		       mib->name, ETH_GSTRING_LEN);
+	}
+}
+EXPORT_SYMBOL_GPL(rtl8366_get_strings);
+
+int rtl8366_get_sset_count(struct dsa_switch *ds)
+{
+	struct realtek_smi *smi = ds->priv;
+
+	return smi->num_mib_counters;
+}
+EXPORT_SYMBOL_GPL(rtl8366_get_sset_count);
+
+void rtl8366_get_ethtool_stats(struct dsa_switch *ds, int port, uint64_t *data)
+{
+	struct realtek_smi *smi = ds->priv;
+	int i;
+	int ret;
+
+	if (port >= smi->num_ports)
+		return;
+
+	for (i = 0; i < smi->num_mib_counters; i++) {
+		struct rtl8366_mib_counter *mib;
+		u64 mibvalue;
+
+		mib = &smi->mib_counters[i];
+		ret = smi->ops->get_mib_counter(smi, port, mib, &mibvalue);
+		if (ret) {
+			dev_err(smi->dev, "error reading MIB counter %s\n",
+				mib->name);
+		}
+		data[i] = mibvalue;
+	}
+}
+EXPORT_SYMBOL_GPL(rtl8366_get_ethtool_stats);
diff --git a/drivers/net/dsa/rtl8366rb.c b/drivers/net/dsa/rtl8366rb.c
new file mode 100644
index 000000000000..765ca72cc399
--- /dev/null
+++ b/drivers/net/dsa/rtl8366rb.c
@@ -0,0 +1,1103 @@
+/*
+ * Realtek SMI subdriver for the Realtek RTL8366RB ethernet switch
+ *
+ * Copyright (C) 2017 Linus Walleij <linus.walleij@linaro.org>
+ * Copyright (C) 2009-2010 Gabor Juhos <juhosg@openwrt.org>
+ * Copyright (C) 2010 Antti Seppälä <a.seppala@gmail.com>
+ * Copyright (C) 2010 Roman Yeryomin <roman@advem.lv>
+ * Copyright (C) 2011 Colin Leitner <colin.leitner@googlemail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include <linux/regmap.h>
+#include <linux/bitops.h>
+#include <linux/interrupt.h>
+#include <linux/irqdomain.h>
+#include <linux/irqchip/chained_irq.h>
+#include <linux/of_irq.h>
+
+#include "realtek-smi.h"
+
+#define RTL8366RB_PORT_NUM_CPU		5
+#define RTL8366RB_NUM_PORTS		6
+#define RTL8366RB_PHY_NO_MAX		4
+#define RTL8366RB_PHY_ADDR_MAX		31
+
+#define RTL8366RB_PAACR0		0x10 /* bits 0..7 = port 0, bits 8..15 = port 1 */
+#define RTL8366RB_PAACR1		0x11 /* bits 0..7 = port 2, bits 8..15 = port 3 */
+#define RTL8366RB_PAACR2		0x12 /* bits 0..7 = port 4, bits 8..15 = port 5 */
+#define RTL8366RB_PAACR_SPEED_10M	0
+#define RTL8366RB_PAACR_SPEED_100M	1
+#define RTL8366RB_PAACR_SPEED_1000M	2
+#define RTL8366RB_PAACR_FULL_DUPLEX	BIT(2)
+#define RTL8366RB_PAACR_LINK_UP		BIT(4)
+#define RTL8366RB_PAACR_TX_PAUSE	BIT(5)
+#define RTL8366RB_PAACR_RX_PAUSE	BIT(6)
+#define RTL8366RB_PAACR_AN		BIT(7)
+
+#define RTL8366RB_PAACR_CPU_PORT	(RTL8366RB_PAACR_SPEED_1000M | \
+					 RTL8366RB_PAACR_FULL_DUPLEX | \
+					 RTL8366RB_PAACR_LINK_UP | \
+					 RTL8366RB_PAACR_TX_PAUSE | \
+					 RTL8366RB_PAACR_RX_PAUSE)
+
+#define RTL8366RB_PSTAT0		0x14 /* bits 0..7 = port 0, bits 8..15 = port 1 */
+#define RTL8366RB_PSTAT1		0x15 /* bits 0..7 = port 2, bits 8..15 = port 3 */
+#define RTL8366RB_PSTAT2		0x16 /* bits 0..7 = port 4, bits 8..15 = port 5 */
+
+#define RTL8366RB_POWER_SAVING_REG	0x21
+
+/* CPU port control reg */
+#define RTL8368RB_CPU_CTRL_REG		0x0061
+#define RTL8368RB_CPU_PORTS_OFF		0
+#define RTL8368RB_CPU_PORTS_MSK		0x00FF
+#define RTL8368RB_CPU_INSTAG		BIT(15) /* enables inserting custom tag length/type 8899 */
+
+#define RTL8366RB_SMAR0			0x0070 /* bits 0..15 */
+#define RTL8366RB_SMAR1			0x0071 /* bits 16..31 */
+#define RTL8366RB_SMAR2			0x0072 /* bits 32..47 */
+
+/* Switch Global Configuration register */
+#define RTL8366RB_SGCR				0x0000
+#define RTL8366RB_SGCR_EN_BC_STORM_CTRL		BIT(0)
+#define RTL8366RB_SGCR_MAX_LENGTH(_x)		(_x << 4)
+#define RTL8366RB_SGCR_MAX_LENGTH_MASK		RTL8366RB_SGCR_MAX_LENGTH(0x3)
+#define RTL8366RB_SGCR_MAX_LENGTH_1522		RTL8366RB_SGCR_MAX_LENGTH(0x0)
+#define RTL8366RB_SGCR_MAX_LENGTH_1536		RTL8366RB_SGCR_MAX_LENGTH(0x1)
+#define RTL8366RB_SGCR_MAX_LENGTH_1552		RTL8366RB_SGCR_MAX_LENGTH(0x2)
+#define RTL8366RB_SGCR_MAX_LENGTH_9216		RTL8366RB_SGCR_MAX_LENGTH(0x3)
+#define RTL8366RB_SGCR_EN_VLAN			BIT(13)
+#define RTL8366RB_SGCR_EN_VLAN_4KTB		BIT(14)
+
+/* Port Enable Control register */
+#define RTL8366RB_PECR				0x0001
+
+/* Port Mirror Control Register */
+#define RTL8366RB_PMCR				0x0007
+#define RTL8366RB_PMCR_SOURCE_PORT(_x)		(_x)
+#define RTL8366RB_PMCR_SOURCE_PORT_MASK		0x000f
+#define RTL8366RB_PMCR_MONITOR_PORT(_x)		((_x) << 4)
+#define RTL8366RB_PMCR_MONITOR_PORT_MASK	0x00f0
+#define RTL8366RB_PMCR_MIRROR_RX		BIT(8)
+#define RTL8366RB_PMCR_MIRROR_TX		BIT(9)
+#define RTL8366RB_PMCR_MIRROR_SPC		BIT(10)
+#define RTL8366RB_PMCR_MIRROR_ISO		BIT(11)
+
+/* Switch Security Control registers */
+#define RTL8366RB_SSCR0				0x0002
+#define RTL8366RB_SSCR1				0x0003
+#define RTL8366RB_SSCR2				0x0004
+#define RTL8366RB_SSCR2_DROP_UNKNOWN_DA		BIT(0)
+
+#define RTL8366RB_RESET_CTRL_REG		0x0100
+#define RTL8366RB_CHIP_CTRL_RESET_HW		1
+#define RTL8366RB_CHIP_CTRL_RESET_SW		(1 << 1)
+
+#define RTL8366RB_CHIP_ID_REG			0x0509
+#define RTL8366RB_CHIP_ID_8366			0x5937
+#define RTL8366RB_CHIP_VERSION_CTRL_REG		0x050A
+#define RTL8366RB_CHIP_VERSION_MASK		0xf
+
+/* PHY registers control */
+#define RTL8366RB_PHY_ACCESS_CTRL_REG		0x8000
+#define RTL8366RB_PHY_CTRL_READ			BIT(0)
+#define RTL8366RB_PHY_CTRL_WRITE		0
+#define RTL8366RB_PHY_ACCESS_BUSY_REG		0x8001
+#define RTL8366RB_PHY_INT_BUSY			BIT(0)
+#define RTL8366RB_PHY_EXT_BUSY			BIT(4)
+#define RTL8366RB_PHY_ACCESS_DATA_REG		0x8002
+#define RTL8366RB_PHY_EXT_CTRL_REG		0x8010
+#define RTL8366RB_PHY_EXT_WRDATA_REG		0x8011
+#define RTL8366RB_PHY_EXT_RDDATA_REG		0x8012
+
+#define RTL8366RB_PHY_REG_MASK			0x1f
+#define RTL8366RB_PHY_PAGE_OFFSET		5
+#define RTL8366RB_PHY_PAGE_MASK			(0xf << 5)
+#define RTL8366RB_PHY_NO_OFFSET			9
+#define RTL8366RB_PHY_NO_MASK			(0x1f << 9)
+
+#define RTL8366RB_VLAN_INGRESS_CTRL2_REG	0x037f
+
+/* LED control registers */
+#define RTL8366RB_LED_BLINKRATE_REG		0x0430
+#define RTL8366RB_LED_BLINKRATE_BIT		0
+#define RTL8366RB_LED_BLINKRATE_MASK		0x0007
+
+#define RTL8366RB_LED_CTRL_REG			0x0431
+#define RTL8366RB_LED_0_1_CTRL_REG		0x0432
+#define RTL8366RB_LED_2_3_CTRL_REG		0x0433
+
+#define RTL8366RB_MIB_COUNT			33
+#define RTL8366RB_GLOBAL_MIB_COUNT		1
+#define RTL8366RB_MIB_COUNTER_PORT_OFFSET	0x0050
+#define RTL8366RB_MIB_COUNTER_BASE		0x1000
+#define RTL8366RB_MIB_CTRL_REG			0x13F0
+#define RTL8366RB_MIB_CTRL_USER_MASK		0x0FFC
+#define RTL8366RB_MIB_CTRL_BUSY_MASK		BIT(0)
+#define RTL8366RB_MIB_CTRL_RESET_MASK		BIT(1)
+#define RTL8366RB_MIB_CTRL_PORT_RESET(_p)	BIT(2 + (_p))
+#define RTL8366RB_MIB_CTRL_GLOBAL_RESET		BIT(11)
+
+#define RTL8366RB_PORT_VLAN_CTRL_BASE		0x0063
+#define RTL8366RB_PORT_VLAN_CTRL_REG(_p)  \
+		(RTL8366RB_PORT_VLAN_CTRL_BASE + (_p) / 4)
+#define RTL8366RB_PORT_VLAN_CTRL_MASK		0xf
+#define RTL8366RB_PORT_VLAN_CTRL_SHIFT(_p)	(4 * ((_p) % 4))
+
+#define RTL8366RB_VLAN_TABLE_READ_BASE		0x018C
+#define RTL8366RB_VLAN_TABLE_WRITE_BASE		0x0185
+
+#define RTL8366RB_TABLE_ACCESS_CTRL_REG		0x0180
+#define RTL8366RB_TABLE_VLAN_READ_CTRL		0x0E01
+#define RTL8366RB_TABLE_VLAN_WRITE_CTRL		0x0F01
+
+#define RTL8366RB_VLAN_MC_BASE(_x)		(0x0020 + (_x) * 3)
+
+#define RTL8366RB_PORT_LINK_STATUS_BASE		0x0014
+#define RTL8366RB_PORT_STATUS_SPEED_MASK	0x0003
+#define RTL8366RB_PORT_STATUS_DUPLEX_MASK	0x0004
+#define RTL8366RB_PORT_STATUS_LINK_MASK		0x0010
+#define RTL8366RB_PORT_STATUS_TXPAUSE_MASK	0x0020
+#define RTL8366RB_PORT_STATUS_RXPAUSE_MASK	0x0040
+#define RTL8366RB_PORT_STATUS_AN_MASK		0x0080
+
+#define RTL8366RB_NUM_VLANS		16
+#define RTL8366RB_NUM_LEDGROUPS		4
+#define RTL8366RB_NUM_VIDS		4096
+#define RTL8366RB_PRIORITYMAX		7
+#define RTL8366RB_FIDMAX		7
+
+#define RTL8366RB_PORT_1		(1 << 0) /* In userspace port 0 */
+#define RTL8366RB_PORT_2		(1 << 1) /* In userspace port 1 */
+#define RTL8366RB_PORT_3		(1 << 2) /* In userspace port 2 */
+#define RTL8366RB_PORT_4		(1 << 3) /* In userspace port 3 */
+#define RTL8366RB_PORT_5		(1 << 4) /* In userspace port 4 */
+
+#define RTL8366RB_PORT_CPU		(1 << 5) /* CPU port */
+
+#define RTL8366RB_PORT_ALL		(RTL8366RB_PORT_1 |	\
+					 RTL8366RB_PORT_2 |	\
+					 RTL8366RB_PORT_3 |	\
+					 RTL8366RB_PORT_4 |	\
+					 RTL8366RB_PORT_5 |	\
+					 RTL8366RB_PORT_CPU)
+
+#define RTL8366RB_PORT_ALL_BUT_CPU	(RTL8366RB_PORT_1 |	\
+					 RTL8366RB_PORT_2 |	\
+					 RTL8366RB_PORT_3 |	\
+					 RTL8366RB_PORT_4 |	\
+					 RTL8366RB_PORT_5)
+
+#define RTL8366RB_PORT_ALL_EXTERNAL	(RTL8366RB_PORT_1 |	\
+					 RTL8366RB_PORT_2 |	\
+					 RTL8366RB_PORT_3 |	\
+					 RTL8366RB_PORT_4)
+
+#define RTL8366RB_PORT_ALL_INTERNAL	 RTL8366RB_PORT_CPU
+
+#define RTL8366RB_VLAN_VID_MASK		0xfff
+#define RTL8366RB_VLAN_PRIORITY_SHIFT	12
+#define RTL8366RB_VLAN_PRIORITY_MASK	0x7
+#define RTL8366RB_VLAN_UNTAG_SHIFT	8
+#define RTL8366RB_VLAN_UNTAG_MASK	0xff
+#define RTL8366RB_VLAN_MEMBER_MASK	0xff
+#define RTL8366RB_VLAN_FID_MASK		0x7
+
+
+/* Port ingress bandwidth control */
+#define RTL8366RB_IB_BASE		0x0200
+#define RTL8366RB_IB_REG(pnum)		(RTL8366RB_IB_BASE + pnum)
+#define RTL8366RB_IB_BDTH_MASK		0x3fff
+#define RTL8366RB_IB_PREIFG_OFFSET	14
+#define RTL8366RB_IB_PREIFG_MASK	(1 << RTL8366RB_IB_PREIFG_OFFSET)
+
+/* Port egress bandwidth control */
+#define RTL8366RB_EB_BASE		0x02d1
+#define RTL8366RB_EB_REG(pnum)		(RTL8366RB_EB_BASE + pnum)
+#define RTL8366RB_EB_BDTH_MASK		0x3fff
+#define RTL8366RB_EB_PREIFG_REG	0x02f8
+#define RTL8366RB_EB_PREIFG_OFFSET	9
+#define RTL8366RB_EB_PREIFG_MASK	(1 << RTL8366RB_EB_PREIFG_OFFSET)
+
+#define RTL8366RB_BDTH_SW_MAX		1048512
+#define RTL8366RB_BDTH_UNIT		64
+#define RTL8366RB_BDTH_REG_DEFAULT	16383
+
+/* QOS */
+#define RTL8366RB_QOS_BIT		15
+#define RTL8366RB_QOS_MASK		(1 << RTL8366RB_QOS_BIT)
+/* Include/Exclude Preamble and IFG (20 bytes). 0:Exclude, 1:Include. */
+#define RTL8366RB_QOS_DEFAULT_PREIFG	1
+
+/* Interrupt handling */
+#define RTL8366RB_INTERRUPT_CONTROL_REG	0x0440
+#define RTL8366RB_INTERRUPT_POLARITY	BIT(0)
+#define RTL8366RB_INTERRUPT_MASK_REG	0x0441
+#define RTL8366RB_INTERRUPT_LINK_CHGALL	GENMASK(11, 0)
+#define RTL8366RB_INTERRUPT_ACLEXCEED	BIT(8)
+#define RTL8366RB_INTERRUPT_STORMEXCEED	BIT(9)
+#define RTL8366RB_INTERRUPT_P4_FIBER	BIT(12)
+#define RTL8366RB_INTERRUPT_P4_UTP	BIT(13)
+#define RTL8366RB_INTERRUPT_VALID	(RTL8366RB_INTERRUPT_LINK_CHGALL | \
+					 RTL8366RB_INTERRUPT_ACLEXCEED | \
+					 RTL8366RB_INTERRUPT_STORMEXCEED | \
+					 RTL8366RB_INTERRUPT_P4_FIBER | \
+					 RTL8366RB_INTERRUPT_P4_UTP)
+#define RTL8366RB_INTERRUPT_STATUS_REG	0x0442
+
+/* bits 0..5 enable force when cleared */
+#define RTL8366RB_MAC_FORCE_CTRL_REG	0x0F11
+
+#define RTL8366RB_GREEN_FEATURE_REG	0x0F51
+#define RTL8366RB_GREEN_FEATURE_MSK	0x0007
+#define RTL8366RB_GREEN_FEATURE_TX	BIT(0)
+#define RTL8366RB_GREEN_FEATURE_RX	BIT(2)
+
+static struct rtl8366_mib_counter rtl8366rb_mib_counters[] = {
+	{ 0,  0, 4, "IfInOctets"				},
+	{ 0,  4, 4, "EtherStatsOctets"				},
+	{ 0,  8, 2, "EtherStatsUnderSizePkts"			},
+	{ 0, 10, 2, "EtherFragments"				},
+	{ 0, 12, 2, "EtherStatsPkts64Octets"			},
+	{ 0, 14, 2, "EtherStatsPkts65to127Octets"		},
+	{ 0, 16, 2, "EtherStatsPkts128to255Octets"		},
+	{ 0, 18, 2, "EtherStatsPkts256to511Octets"		},
+	{ 0, 20, 2, "EtherStatsPkts512to1023Octets"		},
+	{ 0, 22, 2, "EtherStatsPkts1024to1518Octets"		},
+	{ 0, 24, 2, "EtherOversizeStats"			},
+	{ 0, 26, 2, "EtherStatsJabbers"				},
+	{ 0, 28, 2, "IfInUcastPkts"				},
+	{ 0, 30, 2, "EtherStatsMulticastPkts"			},
+	{ 0, 32, 2, "EtherStatsBroadcastPkts"			},
+	{ 0, 34, 2, "EtherStatsDropEvents"			},
+	{ 0, 36, 2, "Dot3StatsFCSErrors"			},
+	{ 0, 38, 2, "Dot3StatsSymbolErrors"			},
+	{ 0, 40, 2, "Dot3InPauseFrames"				},
+	{ 0, 42, 2, "Dot3ControlInUnknownOpcodes"		},
+	{ 0, 44, 4, "IfOutOctets"				},
+	{ 0, 48, 2, "Dot3StatsSingleCollisionFrames"		},
+	{ 0, 50, 2, "Dot3StatMultipleCollisionFrames"		},
+	{ 0, 52, 2, "Dot3sDeferredTransmissions"		},
+	{ 0, 54, 2, "Dot3StatsLateCollisions"			},
+	{ 0, 56, 2, "EtherStatsCollisions"			},
+	{ 0, 58, 2, "Dot3StatsExcessiveCollisions"		},
+	{ 0, 60, 2, "Dot3OutPauseFrames"			},
+	{ 0, 62, 2, "Dot1dBasePortDelayExceededDiscards"	},
+	{ 0, 64, 2, "Dot1dTpPortInDiscards"			},
+	{ 0, 66, 2, "IfOutUcastPkts"				},
+	{ 0, 68, 2, "IfOutMulticastPkts"			},
+	{ 0, 70, 2, "IfOutBroadcastPkts"			},
+};
+
+static int rtl8366rb_get_mib_counter(struct realtek_smi *smi,
+				     int port,
+				     struct rtl8366_mib_counter *mib,
+				     u64 *mibvalue)
+{
+	u32 addr, val;
+	int ret;
+	int i;
+
+	addr = RTL8366RB_MIB_COUNTER_BASE +
+		RTL8366RB_MIB_COUNTER_PORT_OFFSET * (port) +
+		mib->offset;
+
+	/*
+	 * Writing access counter address first
+	 * then ASIC will prepare 64bits counter wait for being retrived
+	 */
+	ret = regmap_write(smi->map, addr, 0); /* Write whatever */
+	if (ret)
+		return ret;
+
+	/* Read MIB control register */
+	ret = regmap_read(smi->map, RTL8366RB_MIB_CTRL_REG, &val);
+	if (ret)
+		return -EIO;
+
+	if (val & RTL8366RB_MIB_CTRL_BUSY_MASK)
+		return -EBUSY;
+
+	if (val & RTL8366RB_MIB_CTRL_RESET_MASK)
+		return -EIO;
+
+	/*
+	 * Read each individual MIB 16 bits at the time
+	 */
+	*mibvalue = 0;
+	for (i = mib->length; i > 0; i--) {
+		ret = regmap_read(smi->map, addr + (i - 1), &val);
+		if (ret)
+			return ret;
+		*mibvalue = (*mibvalue << 16) | (val & 0xFFFF);
+	}
+	return 0;
+}
+
+static u32 rtl8366rb_get_irqmask(struct irq_data *d)
+{
+	int line = irqd_to_hwirq(d);
+	u32 val;
+
+	/*
+	 * For line interrupts we combine link down in bits
+	 * 6..11 with link up in bits 0..5 into one interrupt.
+	 */
+	if (line < 12)
+		val = BIT(line) | BIT(line+6);
+	else
+		val = BIT(line);
+	return val;
+}
+
+static void rtl8366rb_mask_irq(struct irq_data *d)
+{
+	struct realtek_smi *smi = irq_data_get_irq_chip_data(d);
+	int ret;
+
+	ret = regmap_update_bits(smi->map, RTL8366RB_INTERRUPT_MASK_REG,
+				 rtl8366rb_get_irqmask(d), 0);
+	if (ret)
+		dev_err(smi->dev, "could not mask IRQ\n");
+}
+
+static void rtl8366rb_unmask_irq(struct irq_data *d)
+{
+        struct realtek_smi *smi = irq_data_get_irq_chip_data(d);
+	int ret;
+
+	ret = regmap_update_bits(smi->map, RTL8366RB_INTERRUPT_MASK_REG,
+				 rtl8366rb_get_irqmask(d),
+				 rtl8366rb_get_irqmask(d));
+	if (ret)
+		dev_err(smi->dev, "could not unmask IRQ\n");
+}
+
+static irqreturn_t rtl8366rb_irq(int irq, void *data)
+{
+	struct realtek_smi *smi = data;
+	u32 stat;
+	int ret;
+
+	/* This clears the IRQ status register */
+	ret = regmap_read(smi->map, RTL8366RB_INTERRUPT_STATUS_REG,
+			  &stat);
+	if (ret) {
+		dev_err(smi->dev, "can't read interrupt status\n");
+		return IRQ_NONE;
+	}
+	stat &= RTL8366RB_INTERRUPT_VALID;
+	if (!stat)
+		return IRQ_NONE;
+	while (stat) {
+		int line = __ffs(stat);
+		int child_irq;
+
+		stat &= ~BIT(line);
+		/*
+		 * For line interrupts we combine link down in bits
+		 * 6..11 with link up in bits 0..5 into one interrupt.
+		 */
+		if (line < 12 && line > 5)
+			line -= 5;
+		child_irq = irq_find_mapping(smi->irqdomain, line);
+		handle_nested_irq(child_irq);
+	}
+	return IRQ_HANDLED;
+}
+
+static struct irq_chip rtl8366rb_irq_chip = {
+	.name = "RTL8366RB",
+	.irq_mask = rtl8366rb_mask_irq,
+	.irq_unmask = rtl8366rb_unmask_irq,
+};
+
+static int rtl8366rb_irq_map(struct irq_domain *domain, unsigned int irq,
+			     irq_hw_number_t hwirq)
+{
+	irq_set_chip_data(irq, domain->host_data);
+	irq_set_chip_and_handler(irq, &rtl8366rb_irq_chip, handle_simple_irq);
+	irq_set_nested_thread(irq, 1);
+	irq_set_noprobe(irq);
+
+	return 0;
+}
+
+static void rtl8366rb_irq_unmap(struct irq_domain *d, unsigned int irq)
+{
+	irq_set_nested_thread(irq, 0);
+	irq_set_chip_and_handler(irq, NULL, NULL);
+	irq_set_chip_data(irq, NULL);
+}
+
+static const struct irq_domain_ops rtl8366rb_irqdomain_ops = {
+	.map = rtl8366rb_irq_map,
+	.unmap = rtl8366rb_irq_unmap,
+	.xlate  = irq_domain_xlate_onecell,
+};
+
+static int rtl8366rb_setup_cascaded_irq(struct realtek_smi *smi)
+{
+	struct device_node *intc = of_get_child_by_name(smi->dev->of_node,
+							"interrupt-controller");
+	unsigned long irq_trig;
+	int irq;
+	int ret;
+	u32 val;
+	int i;
+
+	if (!intc) {
+		dev_err(smi->dev, "missing child interrupt-controller node\n");
+		return -EINVAL;
+	}
+	/* RB8366RB IRQs cascade off this one */
+	irq = of_irq_get(intc, 0);
+	if (irq <= 0) {
+		dev_err(smi->dev, "failed to get parent IRQ\n");
+		return irq ?: -EINVAL;
+	}
+
+	/* This clears the IRQ status register */
+	ret = regmap_read(smi->map, RTL8366RB_INTERRUPT_STATUS_REG,
+			  &val);
+	if (ret) {
+		dev_err(smi->dev, "can't read interrupt status\n");
+		return ret;
+	}
+
+	/* Fetch IRQ edge information from the descriptor */
+	irq_trig = irqd_get_trigger_type(irq_get_irq_data(irq));
+	switch (irq_trig) {
+	case IRQF_TRIGGER_RISING:
+	case IRQF_TRIGGER_HIGH:
+		dev_info(smi->dev, "active high/rising IRQ\n");
+		val = 0;
+		break;
+	case IRQF_TRIGGER_FALLING:
+	case IRQF_TRIGGER_LOW:
+		dev_info(smi->dev, "active low/falling IRQ\n");
+		val = RTL8366RB_INTERRUPT_POLARITY;
+		break;
+	};
+	ret = regmap_update_bits(smi->map, RTL8366RB_INTERRUPT_CONTROL_REG,
+				 RTL8366RB_INTERRUPT_POLARITY,
+				 val);
+	if (ret) {
+		dev_err(smi->dev, "could not configure IRQ polarity\n");
+		return ret;
+	}
+
+	ret = devm_request_threaded_irq(smi->dev, irq, NULL,
+					rtl8366rb_irq, IRQF_ONESHOT,
+					"RTL8366RB", smi);
+	if (ret) {
+		dev_err(smi->dev, "unable to request irq: %d\n", ret);
+		return ret;
+	}
+	smi->irqdomain = irq_domain_add_linear(intc, smi->num_ports,
+					       &rtl8366rb_irqdomain_ops, smi);
+	if (!smi->irqdomain) {
+		dev_err(smi->dev, "failed to create IRQ domain\n");
+		return -EINVAL;
+	}
+	for (i = 0; i < smi->num_ports; i++)
+		irq_set_parent(irq_create_mapping(smi->irqdomain, i), irq);
+
+	return 0;
+}
+
+/*
+ * This jam table activates "green ethernet", which means low power mode
+ * and is claimed to detect the cable length and not use more power than
+ * necessary, and the ports should enter power saving mode 10 seconds after
+ * a cable is disconnected.
+ */
+static const u32 rtl8366rb_green_jam[][2] = {
+	{0xBE78, 0x323C},
+	{0xBE77, 0x5000},
+	{0xBE2E, 0x7BA7},
+	{0xBE59, 0x3459},
+	{0xBE5A, 0x745A},
+	{0xBE5B, 0x785C},
+	{0xBE5C, 0x785C},
+	{0xBE6E, 0xE120},
+	{0xBE79, 0x323C},
+};
+
+static int rtl8366rb_setup(struct dsa_switch *ds)
+{
+	struct realtek_smi *smi = ds->priv;
+	u32 chip_id = 0;
+	u32 chip_ver = 0;
+	u32 val;
+	int ret;
+	int i;
+
+	ret = regmap_read(smi->map, RTL8366RB_CHIP_ID_REG, &chip_id);
+	if (ret) {
+		dev_err(smi->dev, "unable to read chip id\n");
+		return ret;
+	}
+
+	switch (chip_id) {
+	case RTL8366RB_CHIP_ID_8366:
+		break;
+	default:
+		dev_err(smi->dev, "unknown chip id (%04x)\n", chip_id);
+		return -ENODEV;
+	}
+
+	ret = regmap_read(smi->map, RTL8366RB_CHIP_VERSION_CTRL_REG,
+			  &chip_ver);
+	if (ret) {
+		dev_err(smi->dev, "unable to read chip version\n");
+		return ret;
+	}
+
+	dev_info(smi->dev, "RTL%04x ver %u chip found\n",
+		 chip_id, chip_ver & RTL8366RB_CHIP_VERSION_MASK);
+
+	/* Set up the "green ethernet" feature */
+	i = 0;
+	while (i < ARRAY_SIZE(rtl8366rb_green_jam)) {
+		ret = regmap_read(smi->map, RTL8366RB_PHY_ACCESS_BUSY_REG,
+				  &val);
+		if (ret)
+			return ret;
+		if (!(val & RTL8366RB_PHY_INT_BUSY)) {
+			ret = regmap_write(smi->map,
+					   RTL8366RB_PHY_ACCESS_CTRL_REG,
+					   RTL8366RB_PHY_CTRL_WRITE);
+			if (ret)
+				return ret;
+			ret = regmap_write(smi->map,
+					   rtl8366rb_green_jam[i][0],
+					   rtl8366rb_green_jam[i][1]);
+			if (ret)
+				return ret;
+			i++;
+		}
+	}
+	ret = regmap_write(smi->map,
+			   RTL8366RB_GREEN_FEATURE_REG,
+			   (chip_ver == 1) ? 0x0007 : 0x0003);
+	if (ret)
+		return ret;
+	/*
+	 * The RTL8366RB PHY driver will set up the PHY registers for power
+	 * saving mode.
+	 */
+
+	/* Force the fixed CPU port into 1Gbit mode, no autonegotiation */
+	ret = regmap_update_bits(smi->map, RTL8366RB_MAC_FORCE_CTRL_REG,
+				 BIT(5), 0);
+	if (ret)
+		return ret;
+
+	ret = regmap_update_bits(smi->map, RTL8366RB_PAACR2,
+				 0xFF00U,
+				 RTL8366RB_PAACR_CPU_PORT << 8);
+	if (ret)
+		return ret;
+
+	ret = regmap_update_bits(smi->map, RTL8366RB_MAC_FORCE_CTRL_REG,
+				 BIT(5), BIT(5));
+	if (ret)
+		return ret;
+
+	/* Vendor driver sets 0x240 in registers 0xc and 0xd (undocumented) */
+	ret = regmap_write(smi->map, 0x0c, 0x240);
+	if (ret)
+		return ret;
+	ret = regmap_write(smi->map, 0x0d, 0x240);
+	if (ret)
+		return ret;
+
+	/*
+	 * FIXME: this disables inserting the custom tag, enable this when we
+	 * support the custom tag in net/dsa.
+	 */
+	ret = regmap_update_bits(smi->map, RTL8368RB_CPU_CTRL_REG,
+				 0xFFFF, BIT(smi->cpu_port));
+
+	/* Make sure we default-enable the fixed CPU port */
+	ret = regmap_update_bits(smi->map, RTL8366RB_PECR,
+				 BIT(smi->cpu_port),
+				 0);
+
+	/* set maximum packet length to 1536 bytes */
+	ret = regmap_update_bits(smi->map, RTL8366RB_SGCR,
+				 RTL8366RB_SGCR_MAX_LENGTH_MASK,
+				 RTL8366RB_SGCR_MAX_LENGTH_1536);
+	if (ret)
+		return ret;
+
+	/* enable learning for all ports */
+	ret = regmap_write(smi->map, RTL8366RB_SSCR0, 0);
+	if (ret)
+		return ret;
+
+	/* enable auto ageing for all ports */
+	ret = regmap_write(smi->map, RTL8366RB_SSCR1, 0);
+	if (ret)
+		return ret;
+
+	/*
+	 * discard VLAN tagged packets if the port is not a member of
+	 * the VLAN with which the packets is associated.
+	 */
+	ret = regmap_write(smi->map, RTL8366RB_VLAN_INGRESS_CTRL2_REG,
+			   RTL8366RB_PORT_ALL);
+	if (ret)
+		return ret;
+
+	/* don't drop packets whose DA has not been learned */
+	ret = regmap_update_bits(smi->map, RTL8366RB_SSCR2,
+				 RTL8366RB_SSCR2_DROP_UNKNOWN_DA, 0);
+	if (ret)
+		return ret;
+
+	/* Issues reset_vlan(), enable_vlan(true) */
+	ret = rtl8366_init_vlan(smi);
+	if (ret)
+		return ret;
+
+	ret = rtl8366rb_setup_cascaded_irq(smi);
+	if (ret)
+		dev_info(smi->dev, "no interrupt support\n");
+
+	return 0;
+}
+
+static int rtl8366rb_set_addr(struct dsa_switch *ds, u8 *addr)
+{
+	struct realtek_smi *smi = ds->priv;
+	u16 val;
+	int ret;
+
+	dev_info(smi->dev, "set MAC: %02X:%02X:%02X:%02X:%02X:%02X\n",
+		 addr[0], addr[1], addr[2], addr[3], addr[4], addr[5]);
+	val = addr[0] << 8 | addr[1];
+	ret = regmap_write(smi->map, RTL8366RB_SMAR0, val);
+	if (ret)
+		return ret;
+	val = addr[2] << 8 | addr[3];
+	ret = regmap_write(smi->map, RTL8366RB_SMAR1, val);
+	if (ret)
+		return ret;
+	val = addr[4] << 8 | addr[5];
+	ret = regmap_write(smi->map, RTL8366RB_SMAR2, val);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static int rtl8366rb_phy_read(struct dsa_switch *ds, int phy, int regnum)
+{
+	struct realtek_smi *smi = ds->priv;
+	u32 val;
+	u32 reg;
+	int ret;
+
+	if (phy > RTL8366RB_PHY_NO_MAX)
+		return -EINVAL;
+
+	ret = regmap_write(smi->map, RTL8366RB_PHY_ACCESS_CTRL_REG,
+			   RTL8366RB_PHY_CTRL_READ);
+	if (ret)
+		return ret;
+
+	reg = 0x8000 | (1 << (phy + RTL8366RB_PHY_NO_OFFSET)) | regnum;
+
+	ret = regmap_write(smi->map, reg, 0);
+	if (ret) {
+		dev_err(smi->dev,
+			"failed to write PHY%d reg %04x @ %04x, ret %d\n",
+			phy, regnum, reg, ret);
+		return ret;
+	}
+
+	ret = regmap_read(smi->map, RTL8366RB_PHY_ACCESS_DATA_REG, &val);
+	if (ret)
+		return ret;
+
+	dev_dbg(smi->dev, "read PHY%d register 0x%04x @ %08x, val <- %04x\n",
+		phy, regnum, reg, val);
+
+	return val;
+}
+
+static int rtl8366rb_phy_write(struct dsa_switch *ds, int phy, int regnum,
+			       u16 val)
+{
+	struct realtek_smi *smi = ds->priv;
+	u32 reg;
+	int ret;
+
+	if (phy > RTL8366RB_PHY_NO_MAX)
+		return -EINVAL;
+
+	ret = regmap_write(smi->map, RTL8366RB_PHY_ACCESS_CTRL_REG,
+			   RTL8366RB_PHY_CTRL_WRITE);
+	if (ret)
+		return ret;
+
+	reg = 0x8000 | (1 << (phy + RTL8366RB_PHY_NO_OFFSET)) | regnum;
+
+	dev_dbg(smi->dev, "write PHY%d register 0x%04x @ %04x, val -> %04x\n",
+		phy, regnum, reg, val);
+
+	ret = regmap_write(smi->map, reg, val);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static enum dsa_tag_protocol rtl8366_get_tag_protocol(struct dsa_switch *ds)
+{
+	/* FIXME: implement the right tagging protocol */
+	return DSA_TAG_PROTO_NONE;
+}
+
+static void rtl8366rb_adjust_link(struct dsa_switch *ds, int port,
+				  struct phy_device *phydev)
+{
+	struct realtek_smi *smi = ds->priv;
+
+	if (port == smi->cpu_port) {
+		dev_info(smi->dev, "adjust link on CPU port\n");
+	}
+}
+
+static int
+rtl8366rb_port_enable(struct dsa_switch *ds, int port,
+		      struct phy_device *phy)
+{
+	struct realtek_smi *smi = ds->priv;
+
+	dev_info(smi->dev, "enable port %d\n", port);
+	return regmap_update_bits(smi->map, RTL8366RB_PECR, BIT(port),
+				  0);
+
+}
+
+static void
+rtl8366rb_port_disable(struct dsa_switch *ds, int port,
+		       struct phy_device *phy)
+{
+	struct realtek_smi *smi = ds->priv;
+
+	dev_info(smi->dev, "disable port %d\n", port);
+	regmap_update_bits(smi->map, RTL8366RB_PECR, BIT(port),
+			   BIT(port));
+}
+
+static int rtl8366rb_get_vlan_4k(struct realtek_smi *smi, u32 vid,
+				 struct rtl8366_vlan_4k *vlan4k)
+{
+	u32 data[3];
+	int ret;
+	int i;
+
+	memset(vlan4k, '\0', sizeof(struct rtl8366_vlan_4k));
+
+	if (vid >= RTL8366RB_NUM_VIDS)
+		return -EINVAL;
+
+	/* write VID */
+	ret = regmap_write(smi->map, RTL8366RB_VLAN_TABLE_WRITE_BASE,
+			   vid & RTL8366RB_VLAN_VID_MASK);
+	if (ret)
+		return ret;
+
+	/* write table access control word */
+	ret = regmap_write(smi->map, RTL8366RB_TABLE_ACCESS_CTRL_REG,
+			   RTL8366RB_TABLE_VLAN_READ_CTRL);
+	if (ret)
+		return ret;
+
+	for (i = 0; i < 3; i++) {
+		ret = regmap_read(smi->map,
+				  RTL8366RB_VLAN_TABLE_READ_BASE + i,
+				  &data[i]);
+		if (ret)
+			return ret;
+	}
+
+	vlan4k->vid = vid;
+	vlan4k->untag = (data[1] >> RTL8366RB_VLAN_UNTAG_SHIFT) &
+			RTL8366RB_VLAN_UNTAG_MASK;
+	vlan4k->member = data[1] & RTL8366RB_VLAN_MEMBER_MASK;
+	vlan4k->fid = data[2] & RTL8366RB_VLAN_FID_MASK;
+
+	return 0;
+}
+
+static int rtl8366rb_set_vlan_4k(struct realtek_smi *smi,
+				 const struct rtl8366_vlan_4k *vlan4k)
+{
+	u32 data[3];
+	int ret;
+	int i;
+
+	if (vlan4k->vid >= RTL8366RB_NUM_VIDS ||
+	    vlan4k->member > RTL8366RB_VLAN_MEMBER_MASK ||
+	    vlan4k->untag > RTL8366RB_VLAN_UNTAG_MASK ||
+	    vlan4k->fid > RTL8366RB_FIDMAX)
+		return -EINVAL;
+
+	data[0] = vlan4k->vid & RTL8366RB_VLAN_VID_MASK;
+	data[1] = (vlan4k->member & RTL8366RB_VLAN_MEMBER_MASK) |
+		  ((vlan4k->untag & RTL8366RB_VLAN_UNTAG_MASK) <<
+			RTL8366RB_VLAN_UNTAG_SHIFT);
+	data[2] = vlan4k->fid & RTL8366RB_VLAN_FID_MASK;
+
+	for (i = 0; i < 3; i++) {
+		ret = regmap_write(smi->map,
+					    RTL8366RB_VLAN_TABLE_WRITE_BASE + i,
+					    data[i]);
+		if (ret)
+			return ret;
+	}
+
+	/* write table access control word */
+	ret = regmap_write(smi->map, RTL8366RB_TABLE_ACCESS_CTRL_REG,
+				    RTL8366RB_TABLE_VLAN_WRITE_CTRL);
+
+	return ret;
+}
+
+static int rtl8366rb_get_vlan_mc(struct realtek_smi *smi, u32 index,
+				 struct rtl8366_vlan_mc *vlanmc)
+{
+	u32 data[3];
+	int ret;
+	int i;
+
+	memset(vlanmc, '\0', sizeof(struct rtl8366_vlan_mc));
+
+	if (index >= RTL8366RB_NUM_VLANS)
+		return -EINVAL;
+
+	for (i = 0; i < 3; i++) {
+		ret = regmap_read(smi->map,
+					   RTL8366RB_VLAN_MC_BASE(index) + i,
+					   &data[i]);
+		if (ret)
+			return ret;
+	}
+
+	vlanmc->vid = data[0] & RTL8366RB_VLAN_VID_MASK;
+	vlanmc->priority = (data[0] >> RTL8366RB_VLAN_PRIORITY_SHIFT) &
+			   RTL8366RB_VLAN_PRIORITY_MASK;
+	vlanmc->untag = (data[1] >> RTL8366RB_VLAN_UNTAG_SHIFT) &
+			RTL8366RB_VLAN_UNTAG_MASK;
+	vlanmc->member = data[1] & RTL8366RB_VLAN_MEMBER_MASK;
+	vlanmc->fid = data[2] & RTL8366RB_VLAN_FID_MASK;
+
+	return 0;
+}
+
+static int rtl8366rb_set_vlan_mc(struct realtek_smi *smi, u32 index,
+				 const struct rtl8366_vlan_mc *vlanmc)
+{
+	u32 data[3];
+	int ret;
+	int i;
+
+	if (index >= RTL8366RB_NUM_VLANS ||
+	    vlanmc->vid >= RTL8366RB_NUM_VIDS ||
+	    vlanmc->priority > RTL8366RB_PRIORITYMAX ||
+	    vlanmc->member > RTL8366RB_VLAN_MEMBER_MASK ||
+	    vlanmc->untag > RTL8366RB_VLAN_UNTAG_MASK ||
+	    vlanmc->fid > RTL8366RB_FIDMAX)
+		return -EINVAL;
+
+	data[0] = (vlanmc->vid & RTL8366RB_VLAN_VID_MASK) |
+		  ((vlanmc->priority & RTL8366RB_VLAN_PRIORITY_MASK) <<
+			RTL8366RB_VLAN_PRIORITY_SHIFT);
+	data[1] = (vlanmc->member & RTL8366RB_VLAN_MEMBER_MASK) |
+		  ((vlanmc->untag & RTL8366RB_VLAN_UNTAG_MASK) <<
+			RTL8366RB_VLAN_UNTAG_SHIFT);
+	data[2] = vlanmc->fid & RTL8366RB_VLAN_FID_MASK;
+
+	for (i = 0; i < 3; i++) {
+		ret = regmap_write(smi->map,
+				   RTL8366RB_VLAN_MC_BASE(index) + i,
+				   data[i]);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static int rtl8366rb_get_mc_index(struct realtek_smi *smi, int port, int *val)
+{
+	u32 data;
+	int ret;
+
+	if (port >= smi->num_ports)
+		return -EINVAL;
+
+	ret = regmap_read(smi->map, RTL8366RB_PORT_VLAN_CTRL_REG(port),
+				   &data);
+	if (ret)
+		return ret;
+
+	*val = (data >> RTL8366RB_PORT_VLAN_CTRL_SHIFT(port)) &
+	       RTL8366RB_PORT_VLAN_CTRL_MASK;
+
+	return 0;
+
+}
+
+static int rtl8366rb_set_mc_index(struct realtek_smi *smi, int port, int index)
+{
+	if (port >= smi->num_ports || index >= RTL8366RB_NUM_VLANS)
+		return -EINVAL;
+
+	return regmap_update_bits(smi->map, RTL8366RB_PORT_VLAN_CTRL_REG(port),
+				RTL8366RB_PORT_VLAN_CTRL_MASK <<
+					RTL8366RB_PORT_VLAN_CTRL_SHIFT(port),
+				(index & RTL8366RB_PORT_VLAN_CTRL_MASK) <<
+					RTL8366RB_PORT_VLAN_CTRL_SHIFT(port));
+}
+
+static bool rtl8366rb_is_vlan_valid(struct realtek_smi *smi, unsigned vlan)
+{
+	unsigned max = RTL8366RB_NUM_VLANS;
+
+	if (smi->vlan4k_enabled)
+		max = RTL8366RB_NUM_VIDS - 1;
+
+	if (vlan == 0 || vlan >= max)
+		return 0;
+
+	return 1;
+}
+
+static int rtl8366rb_enable_vlan(struct realtek_smi *smi, bool enable)
+{
+	return regmap_update_bits(smi->map, RTL8366RB_SGCR, RTL8366RB_SGCR_EN_VLAN,
+				  enable ? RTL8366RB_SGCR_EN_VLAN : 0);
+}
+
+static int rtl8366rb_enable_vlan4k(struct realtek_smi *smi, bool enable)
+{
+	return regmap_update_bits(smi->map, RTL8366RB_SGCR,
+				  RTL8366RB_SGCR_EN_VLAN_4KTB,
+				  enable ? RTL8366RB_SGCR_EN_VLAN_4KTB : 0);
+}
+
+static int rtl8366rb_reset_chip(struct realtek_smi *smi)
+{
+	int timeout = 10;
+	u32 val;
+	int ret;
+
+	realtek_smi_write_reg_noack(smi, RTL8366RB_RESET_CTRL_REG,
+				    RTL8366RB_CHIP_CTRL_RESET_HW);
+	do {
+		msleep(1);
+		ret = regmap_read(smi->map, RTL8366RB_RESET_CTRL_REG, &val);
+		if (ret)
+			return ret;
+
+		if (!(val & RTL8366RB_CHIP_CTRL_RESET_HW))
+			break;
+	} while (--timeout);
+
+	if (!timeout) {
+		dev_err(smi->dev, "timeout waiting for the switch to reset\n");
+		return -EIO;
+	}
+
+	return 0;
+}
+
+static int rtl8366rb_detect(struct realtek_smi *smi)
+{
+	struct device *dev = smi->dev;
+	int ret;
+	u32 val;
+
+	/* Detect device */
+	ret = regmap_read(smi->map, 0x5c, &val);
+	if (ret) {
+		dev_err(dev, "can't get chip ID (%d)\n", ret);
+		return ret;
+	}
+
+	switch(val) {
+	case 0x6027:
+		dev_info(dev, "found an RTL8366S switch\n");
+		dev_err(dev, "this switch is not yet supported, submit patches!\n");
+		return -ENODEV;
+		break;
+	case 0x5937:
+		dev_info(dev, "found an RTL8366RB switch\n");
+		smi->cpu_port = RTL8366RB_PORT_NUM_CPU;
+		smi->num_ports = RTL8366RB_NUM_PORTS;
+		smi->num_vlan_mc = RTL8366RB_NUM_VLANS;
+		smi->mib_counters = rtl8366rb_mib_counters;
+		smi->num_mib_counters = ARRAY_SIZE(rtl8366rb_mib_counters);
+		break;
+	default:
+		dev_info(dev, "found an Unknown Realtek switch (id=0x%04x)\n",
+			 val);
+		break;
+	}
+
+	ret = rtl8366rb_reset_chip(smi);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static const struct dsa_switch_ops rtl8366rb_switch_ops = {
+	.get_tag_protocol = rtl8366_get_tag_protocol,
+	.setup = rtl8366rb_setup,
+	.set_addr = rtl8366rb_set_addr,
+	.adjust_link = rtl8366rb_adjust_link,
+	.get_strings = rtl8366_get_strings,
+	.get_ethtool_stats = rtl8366_get_ethtool_stats,
+	.get_sset_count = rtl8366_get_sset_count,
+	.port_vlan_filtering = rtl8366_vlan_filtering,
+	.port_vlan_prepare = rtl8366_vlan_prepare,
+	.port_vlan_add = rtl8366_vlan_add,
+	.port_vlan_del = rtl8366_vlan_del,
+	.phy_read = rtl8366rb_phy_read,
+	.phy_write = rtl8366rb_phy_write,
+	.port_enable = rtl8366rb_port_enable,
+	.port_disable = rtl8366rb_port_disable,
+};
+
+static const struct realtek_smi_ops rtl8366rb_smi_ops = {
+	.detect		= rtl8366rb_detect,
+	.get_vlan_mc	= rtl8366rb_get_vlan_mc,
+	.set_vlan_mc	= rtl8366rb_set_vlan_mc,
+	.get_vlan_4k	= rtl8366rb_get_vlan_4k,
+	.set_vlan_4k	= rtl8366rb_set_vlan_4k,
+	.get_mc_index	= rtl8366rb_get_mc_index,
+	.set_mc_index	= rtl8366rb_set_mc_index,
+	.get_mib_counter = rtl8366rb_get_mib_counter,
+	.is_vlan_valid	= rtl8366rb_is_vlan_valid,
+	.enable_vlan	= rtl8366rb_enable_vlan,
+	.enable_vlan4k	= rtl8366rb_enable_vlan4k,
+};
+
+const struct realtek_smi_variant rtl8366rb_variant = {
+	.ds_ops = &rtl8366rb_switch_ops,
+	.ops = &rtl8366rb_smi_ops,
+	.clk_delay = 10,
+	.cmd_read = 0xa9,
+	.cmd_write = 0xa8,
+};
+EXPORT_SYMBOL_GPL(rtl8366rb_variant);
-- 
2.13.6

^ permalink raw reply related	[flat|nested] 32+ messages in thread

* Re: [PATCH 3/4] RFC: net: dsa: Add bindings for Realtek SMI DSAs
  2017-11-05 23:19 ` [PATCH 3/4] RFC: net: dsa: Add bindings for Realtek SMI DSAs Linus Walleij
@ 2017-11-05 23:48   ` Andrew Lunn
       [not found]     ` <20171105234831.GA24822-g2DYL2Zd6BY@public.gmane.org>
  0 siblings, 1 reply; 32+ messages in thread
From: Andrew Lunn @ 2017-11-05 23:48 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Vivien Didelot, Florian Fainelli, netdev, Antti Seppälä,
	Roman Yeryomin, Colin Leitner, Gabor Juhos, devicetree

> This interrupt construction is similar to how we handle
> interrupt controllers inside PCI bridges etc.

Hi Linus

Your interrupt handling is going in the right direction, but needs
further work. The PHY interrupt is a phy property, so should be in the
PHY node in device tree.

The Marvell driver gives an example of this, and
vf610-zii-dev-rev-c.dts is an example DT blob you can look at.

> +	ports {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		reg = <0>;
> +		port@0 {
> +			reg = <0>;
> +			label = "lan0";

So here, you should have a

   	     	    	phy-handle = <&phy0>;

linking this MAC to the PHY connected to it.


> +		};

And then an MDIO bus, listing the PHYs

               mdio {
                        #address-cells = <1>;
                        #size-cells = <0>;

                        phy0: phy@0 {
                                reg = <0>;
				interrupt-parent = <&switch_intc>;
				interrupts = <0>;
                        };

It is here you list the interrupts. And the PHY subsystem will link
the interrupt to the PHY when it enumerate the MDIO bus.

You have most of the code already for implementing the MDIO bus. The
rest you can probably borrow from the mv88e6xxx driver.

     Andrew

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver
  2017-11-05 23:19 ` [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver Linus Walleij
@ 2017-11-05 23:59   ` Andrew Lunn
  2017-11-06  8:25     ` Linus Walleij
  2017-11-09 12:49   ` Roman Yeryomin
  1 sibling, 1 reply; 32+ messages in thread
From: Andrew Lunn @ 2017-11-05 23:59 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Vivien Didelot, Florian Fainelli, netdev, Antti Seppälä,
	Roman Yeryomin, Colin Leitner, Gabor Juhos

Hi Linus

> +static int realtek_smi_read_reg(struct realtek_smi *smi, u32 addr, u32 *data)
> +{
> +	unsigned long flags;
> +	u8 lo = 0;
> +	u8 hi = 0;
> +	int ret;
> +
> +	spin_lock_irqsave(&smi->lock, flags);
> +
> +	realtek_smi_start(smi);
> +
> +	/* send READ command */
> +	ret = realtek_smi_write_byte(smi, smi->cmd_read);
> +	if (ret)
> +		goto out;
> +
> +	/* set ADDR[7:0] */
> +	ret = realtek_smi_write_byte(smi, addr & 0xff);
> +	if (ret)
> +		goto out;
> +
> +	/* set ADDR[15:8] */
> +	ret = realtek_smi_write_byte(smi, addr >> 8);
> +	if (ret)
> +		goto out;
> +
> +	/* read DATA[7:0] */
> +	realtek_smi_read_byte0(smi, &lo);
> +	/* read DATA[15:8] */
> +	realtek_smi_read_byte1(smi, &hi);
> +
> +	*data = ((u32) lo) | (((u32) hi) << 8);

If i'm reading this correct, addr is a u16 and data is also u16?  So
it is pretty similar to SMI.

I'm wondering if this should be modelled as a normal MDIO bus? Put the
driver as drivers/net/mdio-realtek.c?

I need to study the rest of the code to see if this is a good idea or
not.

	Andrew

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver
  2017-11-05 23:59   ` Andrew Lunn
@ 2017-11-06  8:25     ` Linus Walleij
  0 siblings, 0 replies; 32+ messages in thread
From: Linus Walleij @ 2017-11-06  8:25 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Vivien Didelot, Florian Fainelli, netdev, Antti Seppälä,
	Roman Yeryomin, Colin Leitner, Gabor Juhos

On Mon, Nov 6, 2017 at 12:59 AM, Andrew Lunn <andrew@lunn.ch> wrote:

> I'm wondering if this should be modelled as a normal MDIO bus? Put the
> driver as drivers/net/mdio-realtek.c?

I looked into it but couldn't find a good fit.

The MDIO bus makes much more sense since more than one vendor
is using it so it's not a one-off. This Realtek is a RTK-specific thing plus
I don't think they are doing it anymore.

It's very confusing since they are using the MDIO electrical specification
and signal names but a totally different custom SMI wire protocol on top.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver
  2017-11-05 23:19 ` [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver Linus Walleij
  2017-11-05 23:59   ` Andrew Lunn
@ 2017-11-09 12:49   ` Roman Yeryomin
  2017-11-09 13:24     ` Andrew Lunn
  1 sibling, 1 reply; 32+ messages in thread
From: Roman Yeryomin @ 2017-11-09 12:49 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, netdev,
	Antti Seppälä,
	Colin Leitner, Gabor Juhos

On 2017-11-06 01:19, Linus Walleij wrote:
> This adds a driver core for the Realtek SMI chips and a subdriver
> for the RTL8366RB. I just added this chip simply because it is
> all I can test.
> 
> The code is a massaged variant of the code that has been sitting
> out-of-tree in OpenWRT for years in the absence of a proper switch
> subsystem. I have tried to credit the original authors wherever
> possible.
> 
> The main changes I've done from the OpenWRT code:
> - Added a callback to set the MAC address.
> - Added an IRQ chip inside the RTL8366RB switch to demux and
>   handle the line state IRQs.
> - Distributed the phy handling out to the PHY driver.
> - Added some RTL8366RB code that was missing in the driver,
>   such as setting up "green ethernet" with a funny jam table
>   and forcing MAC5 (the CPU port) into 1 GBit.
> 

Although it could be a good thing to bring this to mainline, I'm kind of 
pessimistic about supporting such switches in DSA/switchdev. IMO 
swconfig does a better job for now.
Unless switchdev could be expanded to support other functions beyond 
VLAN, like port rate control, ACL, HW NAT (no switchdev L3 offload 
doesn't fit this), etc.
Or at least provide some centralized API for others, like [1].

Or maybe I overlooked something and it can be done already?


Regards,
Roman


Links:
[1] https://marc.info/?l=linux-netdev&m=150972281109740

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver
  2017-11-09 12:49   ` Roman Yeryomin
@ 2017-11-09 13:24     ` Andrew Lunn
  2017-11-09 15:11       ` Roman Yeryomin
  2017-11-10 12:17       ` Egil Hjelmeland
  0 siblings, 2 replies; 32+ messages in thread
From: Andrew Lunn @ 2017-11-09 13:24 UTC (permalink / raw)
  To: Roman Yeryomin
  Cc: Linus Walleij, Vivien Didelot, Florian Fainelli, netdev,
	Antti Seppälä,
	Colin Leitner, Gabor Juhos

> Although it could be a good thing to bring this to mainline, I'm kind of
> pessimistic about supporting such switches in DSA/switchdev. IMO swconfig
> does a better job for now.

I think the important point here is "... for now"

> Unless switchdev could be expanded to support other functions beyond VLAN,
> like port rate control, ACL, HW NAT (no switchdev L3 offload doesn't fit
> this), etc.

Switchdev allows offloading of TC. So port rate control would be
implemented via TC. By ACL do you mean filtering MAC addresses?
iptables? The Broadcom SF2 allows some access to its TCAM using
standard methods. More will come with time. Offload of iptables is in
the works. Pablo posted some patches this month laying the foundations
of HW NAT.

What you request are in the works.

What should also be considered is who is pushing swithdev and DSA
forward, and for what market.

Pure switchdev drivers is mostly being pushed forward for Top or Rack
switches. Big switches, 10G, 40G, 100G ports and lots of them. L3
routing, etc.

switchdev/DSA is mostly being pushed forward by industrial
applications. Switches in big vehicles, trains, planes. Industrial
plant control.

The people pushing stuff forward currently have your list of features
as Nice to Have, so progress is slow in that area. It needs somebody
who cares about these features, needs these features, to dig in and do
the work.

    Andrew

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver
  2017-11-09 13:24     ` Andrew Lunn
@ 2017-11-09 15:11       ` Roman Yeryomin
  2017-11-09 15:38         ` Andrew Lunn
  2017-11-10 12:17       ` Egil Hjelmeland
  1 sibling, 1 reply; 32+ messages in thread
From: Roman Yeryomin @ 2017-11-09 15:11 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Linus Walleij, Vivien Didelot, Florian Fainelli, netdev,
	Antti Seppälä,
	Colin Leitner, Gabor Juhos

On 2017-11-09 15:24, Andrew Lunn wrote:
>> Although it could be a good thing to bring this to mainline, I'm kind 
>> of
>> pessimistic about supporting such switches in DSA/switchdev. IMO 
>> swconfig
>> does a better job for now.
> 
> I think the important point here is "... for now"

... as always, probably

>> Unless switchdev could be expanded to support other functions beyond 
>> VLAN,
>> like port rate control, ACL, HW NAT (no switchdev L3 offload doesn't 
>> fit
>> this), etc.
> 
> Switchdev allows offloading of TC. So port rate control would be
> implemented via TC.

That's interesting. Are there any examples implemented?

> By ACL do you mean filtering MAC addresses?

Not only. Usually ACL means defining action with rules matching MAC/IP 
address, physical or TCP/IP port, VID, Ethertype or even custom bytes.
And actions could be drop, assign rate, change VID/priority, force L3 
offload or mirroring, redirect/copy to CPU port.

> iptables? The Broadcom SF2 allows some access to its TCAM using
> standard methods. More will come with time.

That's OK, if it's doable with current design.

> Offload of iptables is in
> the works. Pablo posted some patches this month laying the foundations
> of HW NAT.

Yes, that what I referred to in my previous email.
But the question how exactly it will be done?
Will the switch support be spread all over the kernel?
Or switchdev will provide API for all the others?


Regards,
Roman

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver
  2017-11-09 15:11       ` Roman Yeryomin
@ 2017-11-09 15:38         ` Andrew Lunn
  2017-11-09 17:21           ` Roman Yeryomin
  0 siblings, 1 reply; 32+ messages in thread
From: Andrew Lunn @ 2017-11-09 15:38 UTC (permalink / raw)
  To: Roman Yeryomin
  Cc: Linus Walleij, Vivien Didelot, Florian Fainelli, netdev,
	Antti Seppälä,
	Colin Leitner, Gabor Juhos

> >>Unless switchdev could be expanded to support other functions beyond
> >>VLAN,
> >>like port rate control, ACL, HW NAT (no switchdev L3 offload doesn't fit
> >>this), etc.
> >
> >Switchdev allows offloading of TC. So port rate control would be
> >implemented via TC.
> 
> That's interesting. Are there any examples implemented?

Mellonex have a few for there TOR switches.

The SF2 has TC mirred implemented. I could also implement this for
Marvell without too much effort.  No DSA switch yet implements port
rate control via TC. But TC would be the correct interface to use.

> >By ACL do you mean filtering MAC addresses?
> 
> Not only. Usually ACL means defining action with rules matching MAC/IP
> address, physical or TCP/IP port, VID, Ethertype or even custom bytes.
> And actions could be drop, assign rate, change VID/priority, force L3
> offload or mirroring, redirect/copy to CPU port.

So this means mapping iptable rules to the switches TCAM. Pablo has
said he is working on this, but there has not been any code posted
yet.

> But the question how exactly it will be done?

The whole idea with switchdev is that your switch interfaces look like
a bunch of linux interfaces, and you configure them just as normal
Linux interface. You setup NAT as you would normally setup NAT. It
then gets pushed down to the hardware. You setup TC rules or ip table
rules on the interface, and they get pushed down to the hardware.

It is just Linux networking as normal. Think of the switch as an
accelerator for what Linux networking can already do.

      Andrew

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver
  2017-11-09 15:38         ` Andrew Lunn
@ 2017-11-09 17:21           ` Roman Yeryomin
  2017-11-09 17:24             ` Andrew Lunn
  0 siblings, 1 reply; 32+ messages in thread
From: Roman Yeryomin @ 2017-11-09 17:21 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Linus Walleij, Vivien Didelot, Florian Fainelli, netdev,
	Antti Seppälä,
	Colin Leitner, Gabor Juhos

On 2017-11-09 17:38, Andrew Lunn wrote:
>> >>Unless switchdev could be expanded to support other functions beyond
>> >>VLAN,
>> >>like port rate control, ACL, HW NAT (no switchdev L3 offload doesn't fit
>> >>this), etc.
>> >
>> >Switchdev allows offloading of TC. So port rate control would be
>> >implemented via TC.
>> 
>> That's interesting. Are there any examples implemented?
> 
> Mellonex have a few for there TOR switches.
> 
> The SF2 has TC mirred implemented. I could also implement this for
> Marvell without too much effort.  No DSA switch yet implements port
> rate control via TC. But TC would be the correct interface to use.
> 
>> >By ACL do you mean filtering MAC addresses?
>> 
>> Not only. Usually ACL means defining action with rules matching MAC/IP
>> address, physical or TCP/IP port, VID, Ethertype or even custom bytes.
>> And actions could be drop, assign rate, change VID/priority, force L3
>> offload or mirroring, redirect/copy to CPU port.
> 
> So this means mapping iptable rules to the switches TCAM. Pablo has
> said he is working on this, but there has not been any code posted
> yet.
> 
>> But the question how exactly it will be done?
> 
> The whole idea with switchdev is that your switch interfaces look like
> a bunch of linux interfaces, and you configure them just as normal
> Linux interface. You setup NAT as you would normally setup NAT. It
> then gets pushed down to the hardware. You setup TC rules or ip table
> rules on the interface, and they get pushed down to the hardware.
> 
> It is just Linux networking as normal. Think of the switch as an
> accelerator for what Linux networking can already do.

Yes, this is exactly how I think of it.
But there are many nuances for every switch/vendor.
The registers writing code is where? switchdev driver?
All I care about is that all the switch specific code should be in one 
place.
If switchdev can provide such place then everything else is a matter of 
time and will, like you said.

Regards,
Roman

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver
  2017-11-09 17:21           ` Roman Yeryomin
@ 2017-11-09 17:24             ` Andrew Lunn
  2017-11-09 18:08               ` Florian Fainelli
  2017-11-10 12:02               ` Roman Yeryomin
  0 siblings, 2 replies; 32+ messages in thread
From: Andrew Lunn @ 2017-11-09 17:24 UTC (permalink / raw)
  To: Roman Yeryomin
  Cc: Linus Walleij, Vivien Didelot, Florian Fainelli, netdev,
	Antti Seppälä,
	Colin Leitner, Gabor Juhos

> The registers writing code is where? switchdev driver?
> All I care about is that all the switch specific code should be in one
> place.

The switch specific code is in the switch specific driver.

Take a look under drivers/net/dsa for the switches which are currently
supported by DSA.

	  Andrew

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver
  2017-11-09 17:24             ` Andrew Lunn
@ 2017-11-09 18:08               ` Florian Fainelli
  2017-11-10  8:16                 ` Linus Walleij
  2017-11-10 12:05                 ` Roman Yeryomin
  2017-11-10 12:02               ` Roman Yeryomin
  1 sibling, 2 replies; 32+ messages in thread
From: Florian Fainelli @ 2017-11-09 18:08 UTC (permalink / raw)
  To: Andrew Lunn, Roman Yeryomin
  Cc: Linus Walleij, Vivien Didelot, netdev, Antti Seppälä,
	Colin Leitner, Gabor Juhos

On 11/09/2017 09:24 AM, Andrew Lunn wrote:
>> The registers writing code is where? switchdev driver?
>> All I care about is that all the switch specific code should be in one
>> place.
> 
> The switch specific code is in the switch specific driver.
> 
> Take a look under drivers/net/dsa for the switches which are currently
> supported by DSA.

And Roman, if you are thinking about converting existing swconfig
drivers from OpenWrt/LEDE into DSA, please do it! The conversion is
reasonably simple even if the APIs do not exactly match. Quite a lot of
swconfig driers in OpenWrt/LEDE are implemented as phy_device, and the
conversion for that is to use a proper mdio_device (see
drivers/net/dsa/b53/b53_mdio.c for an example).

For the record, I tried submitting swconfig back in 2013, but this was
rejected under the premise that it did not follow the simple paradigm
that switch ports must be network devices. Also, swconfig is too
permissive in that it allows switch drivers to come up with their own
netlink attributes, whereas the desire is to standardize as much as
possible on features, even if there is just one implementation for that.

The downside of not using swconfig is that you need multiple tools,
iproute2 namely in order to obtain the same type of configuration, but
this is a small price to pay because DSA is upstream, and upstream
usually wins, and it wins even more when people start contributing the
things they see missing.

Thanks
-- 
Florian

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver
  2017-11-09 18:08               ` Florian Fainelli
@ 2017-11-10  8:16                 ` Linus Walleij
  2017-11-10 12:05                 ` Roman Yeryomin
  1 sibling, 0 replies; 32+ messages in thread
From: Linus Walleij @ 2017-11-10  8:16 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: Andrew Lunn, Roman Yeryomin, Vivien Didelot, netdev,
	Antti Seppälä,
	Colin Leitner, Gabor Juhos

On Thu, Nov 9, 2017 at 7:08 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:

> if you are thinking about converting existing swconfig
> drivers from OpenWrt/LEDE into DSA, please do it! The conversion is
> reasonably simple even if the APIs do not exactly match.

I can confirm this :)

It's exactly what I did for this Realtek thingie and it wasn't
that hard.

> Quite a lot of
> swconfig driers in OpenWrt/LEDE are implemented as phy_device, and the
> conversion for that is to use a proper mdio_device (see
> drivers/net/dsa/b53/b53_mdio.c for an example).

I found a nice split here with the DSA device forking off some
MDIO children, it's really neat and works well.

I just had to patch in some IRQ (link change) support as it
was relying on polling. I'm working in getting
that in shape so we can move ahead with it, as you can see
I took the approach of letting the DSA device present an irqchip
that the PHY can pick an IRQ from and it works like a charm.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver
  2017-11-09 17:24             ` Andrew Lunn
  2017-11-09 18:08               ` Florian Fainelli
@ 2017-11-10 12:02               ` Roman Yeryomin
  2017-11-10 13:51                 ` Andrew Lunn
  1 sibling, 1 reply; 32+ messages in thread
From: Roman Yeryomin @ 2017-11-10 12:02 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Linus Walleij, Vivien Didelot, Florian Fainelli, netdev,
	Antti Seppälä,
	Colin Leitner, Gabor Juhos

On 2017-11-09 19:24, Andrew Lunn wrote:
>> The registers writing code is where? switchdev driver?
>> All I care about is that all the switch specific code should be in one
>> place.
> 
> The switch specific code is in the switch specific driver.
> 
> Take a look under drivers/net/dsa for the switches which are currently
> supported by DSA.
> 

OK, so looks like DSA is actually what I need. I just didn't see a clear 
implementation path for e.g. ACL functions.
Correct me if I'm wrong, to add support for ar8327 ACL or port rate 
control I should expand struct dsa_switch_ops, add appropriate 
infrastructure in netfilter/tc subsystem and actually implement in 
drivers/net/dsa/qca8k.c ?

Regards,
Roman

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver
  2017-11-09 18:08               ` Florian Fainelli
  2017-11-10  8:16                 ` Linus Walleij
@ 2017-11-10 12:05                 ` Roman Yeryomin
  1 sibling, 0 replies; 32+ messages in thread
From: Roman Yeryomin @ 2017-11-10 12:05 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: Andrew Lunn, Linus Walleij, Vivien Didelot, netdev,
	Antti Seppälä,
	Colin Leitner, Gabor Juhos

On 2017-11-09 20:08, Florian Fainelli wrote:
> On 11/09/2017 09:24 AM, Andrew Lunn wrote:
>>> The registers writing code is where? switchdev driver?
>>> All I care about is that all the switch specific code should be in 
>>> one
>>> place.
>> 
>> The switch specific code is in the switch specific driver.
>> 
>> Take a look under drivers/net/dsa for the switches which are currently
>> supported by DSA.
> 
> And Roman, if you are thinking about converting existing swconfig
> drivers from OpenWrt/LEDE into DSA, please do it! The conversion is
> reasonably simple even if the APIs do not exactly match. Quite a lot of
> swconfig driers in OpenWrt/LEDE are implemented as phy_device, and the
> conversion for that is to use a proper mdio_device (see
> drivers/net/dsa/b53/b53_mdio.c for an example).

Yes, I'm thinking about that from time to time :)

> For the record, I tried submitting swconfig back in 2013, but this was
> rejected under the premise that it did not follow the simple paradigm
> that switch ports must be network devices. Also, swconfig is too
> permissive in that it allows switch drivers to come up with their own
> netlink attributes, whereas the desire is to standardize as much as
> possible on features, even if there is just one implementation for 
> that.

Yes, saw it back then...

> The downside of not using swconfig is that you need multiple tools,
> iproute2 namely in order to obtain the same type of configuration, but
> this is a small price to pay because DSA is upstream, and upstream
> usually wins, and it wins even more when people start contributing the
> things they see missing.

Fully agree here


Regards,
Roman

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver
  2017-11-09 13:24     ` Andrew Lunn
  2017-11-09 15:11       ` Roman Yeryomin
@ 2017-11-10 12:17       ` Egil Hjelmeland
  2017-11-10 14:01         ` Andrew Lunn
  1 sibling, 1 reply; 32+ messages in thread
From: Egil Hjelmeland @ 2017-11-10 12:17 UTC (permalink / raw)
  To: Andrew Lunn, Roman Yeryomin
  Cc: Linus Walleij, Vivien Didelot, Florian Fainelli, netdev,
	Antti Seppälä,
	Colin Leitner, Gabor Juhos

On 09. nov. 2017 14:24, Andrew Lunn wrote:
> What should also be considered is who is pushing swithdev and DSA
> forward, and for what market.
> 
> Pure switchdev drivers is mostly being pushed forward for Top or Rack
> switches. Big switches, 10G, 40G, 100G ports and lots of them. L3
> routing, etc.
> 
> switchdev/DSA is mostly being pushed forward by industrial
> applications. Switches in big vehicles, trains, planes. Industrial
> plant control.
> 

Out of curiosity: Are there fundamental reasons why ToR switches don't 
use the DSA model, or is it more historical?

> 
>      Andrew
> 

Egil

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver
  2017-11-10 12:02               ` Roman Yeryomin
@ 2017-11-10 13:51                 ` Andrew Lunn
  0 siblings, 0 replies; 32+ messages in thread
From: Andrew Lunn @ 2017-11-10 13:51 UTC (permalink / raw)
  To: Roman Yeryomin
  Cc: Linus Walleij, Vivien Didelot, Florian Fainelli, netdev,
	Antti Seppälä,
	Colin Leitner, Gabor Juhos

> OK, so looks like DSA is actually what I need. I just didn't see a clear
> implementation path for e.g. ACL functions.

> Correct me if I'm wrong, to add support for ar8327 ACL or port rate control
> I should expand struct dsa_switch_ops, add appropriate infrastructure in
> netfilter/tc subsystem and actually implement in drivers/net/dsa/qca8k.c ?

It would probably be a good idea to start by telling us about the
capabilities of the port rate control. Ideally, you don't want to
modify the tc subsystem. You just want to use existing tc options
which matches what the port can do, and offload it. The following
patch might help you plumb it in...

commit f50f212749e8a28803af3628acbeb85ee0458ed5
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Mon Jan 30 12:41:40 2017 -0800

    net: dsa: Add plumbing for port mirroring
    
    Add necessary plumbing at the slave network device level to have switch
    drivers implement ndo_setup_tc() and most particularly the cls_matchall
    classifier. We add support for two switch operations:
    
    port_add_mirror and port_del_mirror() which configure, on a per-port
    basis the mirror parameters requested from the cls_matchall classifier.
    
    Code is largely borrowed from the Mellanox Spectrum switch driver.

ACL is more effort. You want to look at what Pablo is doing about
offloading his stuff. And see if Mellanox have anything in there
driver. It is often the case that Mallanox implements something first,
and when we figure out how to borrow the code for DSA.

    Andrew

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver
  2017-11-10 12:17       ` Egil Hjelmeland
@ 2017-11-10 14:01         ` Andrew Lunn
  0 siblings, 0 replies; 32+ messages in thread
From: Andrew Lunn @ 2017-11-10 14:01 UTC (permalink / raw)
  To: Egil Hjelmeland
  Cc: Roman Yeryomin, Linus Walleij, Vivien Didelot, Florian Fainelli,
	netdev, Antti Seppälä,
	Colin Leitner, Gabor Juhos

> Out of curiosity: Are there fundamental reasons why ToR switches don't use
> the DSA model, or is it more historical?

Yes, there is a fundamental reason.

https://www.netdevconf.org/2.1/session.html?lunn_didelot_fainelli

DSA always has a host Ethernet interface connected to a port of the
switch.

A pure switchdev device does not. Often, the switch is a PCIe
device. It DMAs frames directly to/from the switch.

Basically, DSA just adds another layer, abstracting that Ethernet
interface into common code which all DSA devices share.

	Andrew

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 3/4] RFC: net: dsa: Add bindings for Realtek SMI DSAs
       [not found]     ` <20171105234831.GA24822-g2DYL2Zd6BY@public.gmane.org>
@ 2017-11-29 12:24       ` Linus Walleij
  2017-11-29 15:56         ` Andrew Lunn
  0 siblings, 1 reply; 32+ messages in thread
From: Linus Walleij @ 2017-11-29 12:24 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Vivien Didelot, Florian Fainelli, netdev-u79uwXL29TY76Z2rM5mHXA,
	Antti Seppälä,
	Roman Yeryomin, Colin Leitner, Gabor Juhos,
	devicetree-u79uwXL29TY76Z2rM5mHXA

On Mon, Nov 6, 2017 at 12:48 AM, Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org> wrote:
>> This interrupt construction is similar to how we handle
>> interrupt controllers inside PCI bridges etc.
>
> Hi Linus
>
> Your interrupt handling is going in the right direction, but needs
> further work. The PHY interrupt is a phy property, so should be in the
> PHY node in device tree.
>
> The Marvell driver gives an example of this, and
> vf610-zii-dev-rev-c.dts is an example DT blob you can look at.
>
>> +     ports {
>> +             #address-cells = <1>;
>> +             #size-cells = <0>;
>> +             reg = <0>;
>> +             port@0 {
>> +                     reg = <0>;
>> +                     label = "lan0";
>
> So here, you should have a
>
>                         phy-handle = <&phy0>;
>
> linking this MAC to the PHY connected to it.

I have the phy-handle in the ethernet controller. This RTL8366RB
thing is just one big PHY as far as I know. So to give the complete picture
this is what I have in my tree right now with the RTL8366RB as PHY
and Gemini ethernet (yeah I'm upstreaming that too...) as the ethernet
controller:

/* This is a RealTek RTL8366RB switch and PHY using SMI over GPIO */
switch {
    compatible = "realtek,rtl8366rb";
    reg = <0>;
    /* 22 = MDIO (has input reads), 21 = MDC (clock, output only) */
    mdc-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>;
    mdio-gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>;
    reset-gpios = <&gpio0 14 GPIO_ACTIVE_LOW>;
    realtek,disable-leds;

    switch_intc: interrupt-controller {
        /* GPIO 15 provides the interrupt */
        interrupt-parent = <&gpio0>;
        interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
        interrupt-controller;
        #address-cells = <0>;
        #interrupt-cells = <1>;
    };

    ports {
        #address-cells = <1>;
        #size-cells = <0>;

        port@0 {
            reg = <0>;
            label = "lan0";
            interrupt-parent = <&switch_intc>;
            interrupts = <0>;
        };
        port@1 {
            reg = <1>;
            label = "lan1";
            interrupt-parent = <&switch_intc>;
            interrupts = <1>;
        };
        port@2 {
            reg = <2>;
            label = "lan2";
            interrupt-parent = <&switch_intc>;
            interrupts = <2>;
        };
        port@3 {
            reg = <3>;
            label = "lan3";
            interrupt-parent = <&switch_intc>;
            interrupts = <3>;
        };
        port@4 {
            reg = <4>;
            label = "wan";
            interrupt-parent = <&switch_intc>;
            interrupts = <12>;
        };
        phy0: port@5 {
            reg = <5>;
            label = "cpu";
            ethernet = <&gmac0>;
            phy-mode = "rgmii";
            fixed-link {
                speed = <1000>;
                full-duplex;
            };
    };
};


ethernet@60000000 {
    compatible = "cortina,gemini-ethernet";
    reg = <0x60000000 0x4000>;
    #address-cells = <1>;
    #size-cells = <1>;
    ranges;

    gmac0: port0 {
        compatible = "cortina,gemini-ethernet-port";
        reg = <0x60008000 0x2000>, /* Port 0 DMA/TOE */
        <0x6000a000 0x2000>; /* Port 0 GMAC */
        interrupt-parent = <&intcon>;
        interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
        resets = <&syscon GEMINI_RESET_GMAC0>;
        clocks = <&syscon GEMINI_CLK_GATE_GMAC0>;
        clock-names = "PCLK";
        phy-mode = "rgmii";
        phy-handle = <&phy0>;
    };
};


> And then an MDIO bus, listing the PHYs
>
>                mdio {
>                         #address-cells = <1>;
>                         #size-cells = <0>;
>
>                         phy0: phy@0 {
>                                 reg = <0>;
>                                 interrupt-parent = <&switch_intc>;
>                                 interrupts = <0>;
>                         };
>
> It is here you list the interrupts. And the PHY subsystem will link
> the interrupt to the PHY when it enumerate the MDIO bus.

I do get that to work with a lot of standard PHY drivers
in drivers/net/phy, that assume they have an IRQ line from
device tree or board files.

However when PHY slave children are spawn from the
internal DSA MDIO bus interrupts are not assigned from the
device tree, so that is why I have a separate patch for that.

> You have most of the code already for implementing the MDIO bus. The
> rest you can probably borrow from the mv88e6xxx driver.

I have a working MDIO bus coming out directly from the SDA core,
so that part is fine. I also patched in the corresponding PHY driver
(a Realtek derivative for this DSA only, so just a few lines add
in the Realtek PHY driver) and it works fine.

I will repost the series as a non-RFC when I have all parts working
and illustrate with a few examples so you see how I set it up.
I hope I didn't turn the entire subsystem on its head or something...

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 3/4] RFC: net: dsa: Add bindings for Realtek SMI DSAs
  2017-11-29 12:24       ` Linus Walleij
@ 2017-11-29 15:56         ` Andrew Lunn
  2017-11-29 21:28           ` Linus Walleij
  0 siblings, 1 reply; 32+ messages in thread
From: Andrew Lunn @ 2017-11-29 15:56 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Vivien Didelot, Florian Fainelli, netdev, Antti Seppälä,
	Roman Yeryomin, Colin Leitner, Gabor Juhos, devicetree

> I have the phy-handle in the ethernet controller. This RTL8366RB
> thing is just one big PHY as far as I know.

Hi Linus

We don't model switches as PHYs. They are their own device type.  And
the internal or external PHYs are just normal PHYs in the linux
model. Meaning their interrupt properties goes in the PHY node in
device tree, as documented in the phy.txt binding documentation.

       Andrew

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 3/4] RFC: net: dsa: Add bindings for Realtek SMI DSAs
  2017-11-29 15:56         ` Andrew Lunn
@ 2017-11-29 21:28           ` Linus Walleij
       [not found]             ` <CACRpkdZVXgFMiHpyUqw7ONYDcq6Htn3rTMRaBJkzd6T3WtX36A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  2017-11-29 21:56             ` Andrew Lunn
  0 siblings, 2 replies; 32+ messages in thread
From: Linus Walleij @ 2017-11-29 21:28 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Vivien Didelot, Florian Fainelli, netdev, Antti Seppälä,
	Roman Yeryomin, Colin Leitner, Gabor Juhos,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On Wed, Nov 29, 2017 at 4:56 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> I have the phy-handle in the ethernet controller. This RTL8366RB
>> thing is just one big PHY as far as I know.
>
> We don't model switches as PHYs. They are their own device type.  And
> the internal or external PHYs are just normal PHYs in the linux
> model. Meaning their interrupt properties goes in the PHY node in
> device tree, as documented in the phy.txt binding documentation.

I do model the PHYs on the switch as PHYs.
They are using the driver in drivers/phy/realtek.c.

The interrupts are assigned to the PHYs not to the Switch.
Just that the PHYs are on the MDIO bus inside the switch, of
course.

The switch however provides an irqchip to demux the interrupts.

I think there is some misunderstanding in what I'm trying to do..

I have tried learning the DSA ideas by reading e.g. your paper:
https://www.netdevconf.org/2.1/papers/distributed-switch-architecture.pdf

So I try my best to conform with these ideas.

I however have a hard time testing things since I don't really have a
system to compare to. What would be useful is to know how
commands like "ip" and "ifconfig" are used on a typical
say home router.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 3/4] RFC: net: dsa: Add bindings for Realtek SMI DSAs
       [not found]             ` <CACRpkdZVXgFMiHpyUqw7ONYDcq6Htn3rTMRaBJkzd6T3WtX36A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2017-11-29 21:48               ` Florian Fainelli
  0 siblings, 0 replies; 32+ messages in thread
From: Florian Fainelli @ 2017-11-29 21:48 UTC (permalink / raw)
  To: Linus Walleij, Andrew Lunn
  Cc: Vivien Didelot, netdev-u79uwXL29TY76Z2rM5mHXA,
	Antti Seppälä,
	Roman Yeryomin, Colin Leitner, Gabor Juhos,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On 11/29/2017 01:28 PM, Linus Walleij wrote:
> On Wed, Nov 29, 2017 at 4:56 PM, Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org> wrote:
>>> I have the phy-handle in the ethernet controller. This RTL8366RB
>>> thing is just one big PHY as far as I know.
>>
>> We don't model switches as PHYs. They are their own device type.  And
>> the internal or external PHYs are just normal PHYs in the linux
>> model. Meaning their interrupt properties goes in the PHY node in
>> device tree, as documented in the phy.txt binding documentation.
> 
> I do model the PHYs on the switch as PHYs.
> They are using the driver in drivers/phy/realtek.c.

That's good.

> 
> The interrupts are assigned to the PHYs not to the Switch.
> Just that the PHYs are on the MDIO bus inside the switch, of
> course.
> 
> The switch however provides an irqchip to demux the interrupts.
> 
> I think there is some misunderstanding in what I'm trying to do..
> 
> I have tried learning the DSA ideas by reading e.g. your paper:
> https://www.netdevconf.org/2.1/papers/distributed-switch-architecture.pdf
> 
> So I try my best to conform with these ideas.
> 
> I however have a hard time testing things since I don't really have a
> system to compare to. What would be useful is to know how
> commands like "ip" and "ifconfig" are used on a typical
> say home router.

There is a mock-up driver: drivers/net/dsa/dsa_loop.c which does not
pass any packets, but at least allows you to exercise user-space tools
and so on.
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 3/4] RFC: net: dsa: Add bindings for Realtek SMI DSAs
  2017-11-29 21:28           ` Linus Walleij
       [not found]             ` <CACRpkdZVXgFMiHpyUqw7ONYDcq6Htn3rTMRaBJkzd6T3WtX36A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2017-11-29 21:56             ` Andrew Lunn
       [not found]               ` <20171129215659.GC1706-g2DYL2Zd6BY@public.gmane.org>
  1 sibling, 1 reply; 32+ messages in thread
From: Andrew Lunn @ 2017-11-29 21:56 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Vivien Didelot, Florian Fainelli, netdev, Antti Seppälä,
	Roman Yeryomin, Colin Leitner, Gabor Juhos,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

Hi Linus

> Just that the PHYs are on the MDIO bus inside the switch, of
> course.

I think the problem might be, you are using the DSA provided MDIO bus.
The Marvell switches has a similar setup in terms of interrupts. The
PHY interrupts appear within the switch. So i implemented an interrupt
controller, just the same as you.

The problem is, the DSA provided MDIO bus is not linked to device
tree. So you cannot have phy nodes in device tree associated to it.

What i did for the Marvell driver is that driver itself implements an
MDIO bus (two actually in some chips), and the internal or external
PHYs are placed on the switch drivers MDIO bus, rather than the DSA
MDIO bus. The switch driver MDIO bus links to an mdio node in device
tree. I can then have interrupt properties in the phys on this MDIO
bus in device tree.

What actually might make sense, is to have the DSA MDIO bus look
inside the switches device tree node and see if there is an mdio
node. If so allow dsa_switch_setup() to use of_mdiobus_register()
instead of mdiobus_register().

      Andrew

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 3/4] RFC: net: dsa: Add bindings for Realtek SMI DSAs
       [not found]               ` <20171129215659.GC1706-g2DYL2Zd6BY@public.gmane.org>
@ 2017-11-29 23:19                 ` Linus Walleij
  2017-11-29 23:26                   ` Florian Fainelli
  0 siblings, 1 reply; 32+ messages in thread
From: Linus Walleij @ 2017-11-29 23:19 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Vivien Didelot, Florian Fainelli, netdev-u79uwXL29TY76Z2rM5mHXA,
	Antti Seppälä,
	Roman Yeryomin, Colin Leitner, Gabor Juhos,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On Wed, Nov 29, 2017 at 10:56 PM, Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org> wrote:

> I think the problem might be, you are using the DSA provided MDIO bus.
> The Marvell switches has a similar setup in terms of interrupts. The
> PHY interrupts appear within the switch. So i implemented an interrupt
> controller, just the same as you.
>
> The problem is, the DSA provided MDIO bus is not linked to device
> tree. So you cannot have phy nodes in device tree associated to it.
>
> What i did for the Marvell driver is that driver itself implements an
> MDIO bus (two actually in some chips), and the internal or external
> PHYs are placed on the switch drivers MDIO bus, rather than the DSA
> MDIO bus. The switch driver MDIO bus links to an mdio node in device
> tree. I can then have interrupt properties in the phys on this MDIO
> bus in device tree.
>
> What actually might make sense, is to have the DSA MDIO bus look
> inside the switches device tree node and see if there is an mdio
> node. If so allow dsa_switch_setup() to use of_mdiobus_register()
> instead of mdiobus_register().

Aha I think I see where my thinking went wrong.

I have been assuming (thought it was intuitive...) that ports and
PHYs are mapped 1:1.

So I assumed the port with reg = <N> is also the PHY with
reg = <N>

So naturally I added the PHY interrupt to the port node.

So you are saying that the PHY and the port are two
very disparate things in DSA terminology?

I guess all ports except the CPU port actually have
a 1:1 mapped PHY though, am I right?

Or are there in pracice things such that reg is different
on the port and the PHY connected to it? Then it makes
much sense to put an MDIO bus inside the switch DT
node and populate the PHY interrupts from there as you
say.

I can take a stab at fixing that if that is what we want.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 3/4] RFC: net: dsa: Add bindings for Realtek SMI DSAs
  2017-11-29 23:19                 ` Linus Walleij
@ 2017-11-29 23:26                   ` Florian Fainelli
       [not found]                     ` <f9bfa1e1-7f05-1e2b-6663-09d4d3bf6a12-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
  2017-12-02 12:56                     ` Linus Walleij
  0 siblings, 2 replies; 32+ messages in thread
From: Florian Fainelli @ 2017-11-29 23:26 UTC (permalink / raw)
  To: Linus Walleij, Andrew Lunn
  Cc: Vivien Didelot, netdev, Antti Seppälä,
	Roman Yeryomin, Colin Leitner, Gabor Juhos,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On 11/29/2017 03:19 PM, Linus Walleij wrote:
> On Wed, Nov 29, 2017 at 10:56 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> 
>> I think the problem might be, you are using the DSA provided MDIO bus.
>> The Marvell switches has a similar setup in terms of interrupts. The
>> PHY interrupts appear within the switch. So i implemented an interrupt
>> controller, just the same as you.
>>
>> The problem is, the DSA provided MDIO bus is not linked to device
>> tree. So you cannot have phy nodes in device tree associated to it.
>>
>> What i did for the Marvell driver is that driver itself implements an
>> MDIO bus (two actually in some chips), and the internal or external
>> PHYs are placed on the switch drivers MDIO bus, rather than the DSA
>> MDIO bus. The switch driver MDIO bus links to an mdio node in device
>> tree. I can then have interrupt properties in the phys on this MDIO
>> bus in device tree.
>>
>> What actually might make sense, is to have the DSA MDIO bus look
>> inside the switches device tree node and see if there is an mdio
>> node. If so allow dsa_switch_setup() to use of_mdiobus_register()
>> instead of mdiobus_register().
> 
> Aha I think I see where my thinking went wrong.
> 
> I have been assuming (thought it was intuitive...) that ports and
> PHYs are mapped 1:1.
> 
> So I assumed the port with reg = <N> is also the PHY with
> reg = <N>
> 
> So naturally I added the PHY interrupt to the port node.
> 
> So you are saying that the PHY and the port are two
> very disparate things in DSA terminology?

Yes, because the port is some sort of simplified Ethernet MAC, whereas
the PHY is the PHY, and it usually exists in the same shape and size
irrespective of whether it's integrated into a switch, being external,
or being internal to a proper Ethernet NIC.

> 
> I guess all ports except the CPU port actually have
> a 1:1 mapped PHY though, am I right?

This is the typical case, but is not universally true.

> 
> Or are there in pracice things such that reg is different
> on the port and the PHY connected to it? Then it makes
> much sense to put an MDIO bus inside the switch DT
> node and populate the PHY interrupts from there as you
> say.

Yes, I have such systems here, Port 0 has its PHY at MDIO address 5 for
instance.

> 
> I can take a stab at fixing that if that is what we want.

While Andrew's suggestion to use of_mdiobus_register() even for the
built-in DSA created slave_mii_bus makes sense, I would rather recommend
you instantiate your own bus (ala mv88e6xxx), such that your DT will
likely look like:

switch@0 {
	compatible = "acme,switch";
	#address-cells = <1>;
	#size-cells = <0>;

	ports {

		port@0 {
			reg = <0>;
			phy-handle = <&phy0>;
		};

		port@1 {
			reg = <1>;
			phy-handle = <&phy1>;
		};

		port@8 {
			reg = <8>;
			ethernet = = <&eth0>;
		};
	};

	mdio {
		compatible = "acme,switch-mdio";

		phy@0 {
			reg = <0>;
		};

		phy@1 {
			reg = <1>;
		};
	};
};

That way it's clear which port maps to which PHY, and that the MDIO
controller is internal within the switch (and so are the PHYs).
-- 
Florian

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 3/4] RFC: net: dsa: Add bindings for Realtek SMI DSAs
       [not found]                     ` <f9bfa1e1-7f05-1e2b-6663-09d4d3bf6a12-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2017-11-29 23:36                       ` Andrew Lunn
  0 siblings, 0 replies; 32+ messages in thread
From: Andrew Lunn @ 2017-11-29 23:36 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: Linus Walleij, Vivien Didelot, netdev-u79uwXL29TY76Z2rM5mHXA,
	Antti Seppälä,
	Roman Yeryomin, Colin Leitner, Gabor Juhos,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

> While Andrew's suggestion to use of_mdiobus_register() even for the
> built-in DSA created slave_mii_bus makes sense, I would rather recommend
> you instantiate your own bus (ala mv88e6xxx), such that your DT will
> likely look like:

Hi Florian

I could still look like this, if the built in slave_mii_bus looked for
the mdio node.

Something like:

diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
index 44e3fb7dec8c..6b64c09413bf 100644
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@ -312,6 +312,7 @@ static void dsa_port_teardown(struct dsa_port *dp)
 
 static int dsa_switch_setup(struct dsa_switch *ds)
 {
+       struct device_node *node;
        int err;
 
        /* Initialize ds->phys_mii_mask before registering the slave MDIO bus
@@ -347,7 +348,11 @@ static int dsa_switch_setup(struct dsa_switch *ds)
 
                dsa_slave_mii_bus_init(ds);
 
-               err = mdiobus_register(ds->slave_mii_bus);
+               if (ds->dev->of_node &&
+                   node = of_get_child_by_name(pdev->dev.of_node, "mdio"))
+                       err = of_mdiobus_register(ds->slave_mii_bus, node);
+               else
+                       err = mdiobus_register(ds->slave_mii_bus);
                if (err < 0)
                        return err;
        }

	Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 32+ messages in thread

* Re: [PATCH 3/4] RFC: net: dsa: Add bindings for Realtek SMI DSAs
  2017-11-29 23:26                   ` Florian Fainelli
       [not found]                     ` <f9bfa1e1-7f05-1e2b-6663-09d4d3bf6a12-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2017-12-02 12:56                     ` Linus Walleij
       [not found]                       ` <CACRpkdYoMVNh8eaTnaDQ59bsh4bC88biLaYSXyhnc4W83PMWzA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  1 sibling, 1 reply; 32+ messages in thread
From: Linus Walleij @ 2017-12-02 12:56 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: Andrew Lunn, Vivien Didelot, netdev, Antti Seppälä,
	Roman Yeryomin, Colin Leitner, Gabor Juhos,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

On Thu, Nov 30, 2017 at 12:26 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 11/29/2017 03:19 PM, Linus Walleij wrote:

>> Or are there in pracice things such that reg is different
>> on the port and the PHY connected to it? Then it makes
>> much sense to put an MDIO bus inside the switch DT
>> node and populate the PHY interrupts from there as you
>> say.
>
> Yes, I have such systems here, Port 0 has its PHY at MDIO address 5 for
> instance.

That explains it.

> switch@0 {
>         compatible = "acme,switch";
>         #address-cells = <1>;
>         #size-cells = <0>;
>
>         ports {
>
>                 port@0 {
>                         reg = <0>;
>                         phy-handle = <&phy0>;
>                 };
>
>                 port@1 {
>                         reg = <1>;
>                         phy-handle = <&phy1>;
>                 };
>
>                 port@8 {
>                         reg = <8>;
>                         ethernet = = <&eth0>;
>                 };
>         };
>
>         mdio {
>                 compatible = "acme,switch-mdio";
>
>                 phy@0 {
>                         reg = <0>;
>                 };
>
>                 phy@1 {
>                         reg = <1>;
>                 };
>         };
> };
>
> That way it's clear which port maps to which PHY, and that the MDIO
> controller is internal within the switch (and so are the PHYs).

So why not:

switch@0 {
        compatible = "acme,switch";
        #address-cells = <1>;
        #size-cells = <0>;

        ports {

                port@0 {
                        reg = <0>;
                        phy@0 {
                             reg = <0>;
                        };
                };

                port@1 {
                        reg = <1>;
                        phy@1 {
                             reg = <1>;
                        };
                };

                port@8 {
                        reg = <8>;
                        ethernet = = <&eth0>;
                };
        };

This avoids the cross-referencing of phandles.

Yours,
Linus Walleii

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 3/4] RFC: net: dsa: Add bindings for Realtek SMI DSAs
       [not found]                       ` <CACRpkdYoMVNh8eaTnaDQ59bsh4bC88biLaYSXyhnc4W83PMWzA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2017-12-04 22:50                         ` Andrew Lunn
  0 siblings, 0 replies; 32+ messages in thread
From: Andrew Lunn @ 2017-12-04 22:50 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Florian Fainelli, Vivien Didelot, netdev-u79uwXL29TY76Z2rM5mHXA,
	Antti Seppälä,
	Roman Yeryomin, Colin Leitner, Gabor Juhos,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS

> So why not:
> 
> switch@0 {
>         compatible = "acme,switch";
>         #address-cells = <1>;
>         #size-cells = <0>;
> 
>         ports {
> 
>                 port@0 {
>                         reg = <0>;
>                         phy@0 {
>                              reg = <0>;
>                         };
>                 };

Hi Linus

So you are suggesting put the PHY node inside the MAC node.

This is sometimes done, but does not describe the hardware. The PHYs
are on an MDIO bus, so device tree should show the MDIO bus and the
PHYs on it.

DSA does have an MDIO bus, so putting the PHYs in the MAC is just
confusing. Although that is not Florians preferred solution, he would
like the DSA driver to export its own MDIO bus and list the PHYs on
it.

	Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH 0/4] RFC: Realtek 83xx SMI driver core
  2017-11-05 23:19 [PATCH 0/4] RFC: Realtek 83xx SMI driver core Linus Walleij
                   ` (3 preceding siblings ...)
  2017-11-05 23:19 ` [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver Linus Walleij
@ 2018-04-02 16:10 ` Carl-Daniel Hailfinger
  4 siblings, 0 replies; 32+ messages in thread
From: Carl-Daniel Hailfinger @ 2018-04-02 16:10 UTC (permalink / raw)
  To: linus.walleij; +Cc: Linux Netdev List

Hi Linus,

did you make any progress with this?
I noticed that the Vodafone Easybox 904xdsl/904lte models both make use
of the RTL8367 switch. About one million of these routers have been
deployed in Germany.
There is an OpenWrt fork at
https://github.com/Quallenauge/Easybox-904-XDSL/commits/master-lede
which depends on the out-of-tree patches which seem to be the basis for
your Realtek 83xx driver patches.

Having your Realtek 83xx patches in the upstream Linux kernel would help
tremendously in getting support for those router models merged in OpenWrt.

Regards,
Carl-Daniel

^ permalink raw reply	[flat|nested] 32+ messages in thread

end of thread, other threads:[~2018-04-02 16:10 UTC | newest]

Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-05 23:19 [PATCH 0/4] RFC: Realtek 83xx SMI driver core Linus Walleij
2017-11-05 23:19 ` [PATCH 1/4] RFC: net/dsa: Allow DSA PHYs to define link IRQs Linus Walleij
2017-11-05 23:19 ` [PATCH 2/4] RFC: net: phy: realtek: Support RTL8366RB variant Linus Walleij
2017-11-05 23:19 ` [PATCH 3/4] RFC: net: dsa: Add bindings for Realtek SMI DSAs Linus Walleij
2017-11-05 23:48   ` Andrew Lunn
     [not found]     ` <20171105234831.GA24822-g2DYL2Zd6BY@public.gmane.org>
2017-11-29 12:24       ` Linus Walleij
2017-11-29 15:56         ` Andrew Lunn
2017-11-29 21:28           ` Linus Walleij
     [not found]             ` <CACRpkdZVXgFMiHpyUqw7ONYDcq6Htn3rTMRaBJkzd6T3WtX36A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-11-29 21:48               ` Florian Fainelli
2017-11-29 21:56             ` Andrew Lunn
     [not found]               ` <20171129215659.GC1706-g2DYL2Zd6BY@public.gmane.org>
2017-11-29 23:19                 ` Linus Walleij
2017-11-29 23:26                   ` Florian Fainelli
     [not found]                     ` <f9bfa1e1-7f05-1e2b-6663-09d4d3bf6a12-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-11-29 23:36                       ` Andrew Lunn
2017-12-02 12:56                     ` Linus Walleij
     [not found]                       ` <CACRpkdYoMVNh8eaTnaDQ59bsh4bC88biLaYSXyhnc4W83PMWzA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-12-04 22:50                         ` Andrew Lunn
2017-11-05 23:19 ` [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver Linus Walleij
2017-11-05 23:59   ` Andrew Lunn
2017-11-06  8:25     ` Linus Walleij
2017-11-09 12:49   ` Roman Yeryomin
2017-11-09 13:24     ` Andrew Lunn
2017-11-09 15:11       ` Roman Yeryomin
2017-11-09 15:38         ` Andrew Lunn
2017-11-09 17:21           ` Roman Yeryomin
2017-11-09 17:24             ` Andrew Lunn
2017-11-09 18:08               ` Florian Fainelli
2017-11-10  8:16                 ` Linus Walleij
2017-11-10 12:05                 ` Roman Yeryomin
2017-11-10 12:02               ` Roman Yeryomin
2017-11-10 13:51                 ` Andrew Lunn
2017-11-10 12:17       ` Egil Hjelmeland
2017-11-10 14:01         ` Andrew Lunn
2018-04-02 16:10 ` [PATCH 0/4] RFC: Realtek 83xx SMI driver core Carl-Daniel Hailfinger

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.