[RFC net-next] net: dsa: rtl8366rb: support bridge offloading

Use port isolation registers to configure bridge offloading.
Remove the VLAN init, as we have proper CPU tag and bridge offloading
support now.

Signed-off-by: DENG Qingfang <dqfext@gmail.com>
---
This is not tested, as I don't have a RTL8366RB board. And I think there
is potential race condition in port_bridge_{join,leave}.

 drivers/net/dsa/rtl8366rb.c | 73 ++++++++++++++++++++++++++++++++++---
 1 file changed, 67 insertions(+), 6 deletions(-)

diff --git a/drivers/net/dsa/rtl8366rb.c b/drivers/net/dsa/rtl8366rb.c
index a89093bc6c6a..9f6e2b361216 100644
--- a/drivers/net/dsa/rtl8366rb.c
+++ b/drivers/net/dsa/rtl8366rb.c

@@ -300,6 +300,12 @@
 #define RTL8366RB_INTERRUPT_STATUS_REG	0x0442
 #define RTL8366RB_NUM_INTERRUPT		14 /* 0..13 */
 
+/* Port isolation registers */
+#define RTL8366RB_PORT_ISO_BASE		0x0F08
+#define RTL8366RB_PORT_ISO(pnum)	(RTL8366RB_PORT_ISO_BASE + (pnum))
+#define RTL8366RB_PORT_ISO_EN		BIT(0)
+#define RTL8366RB_PORT_ISO_PORTS_MASK	GENMASK(7, 1)
+
 /* bits 0..5 enable force when cleared */
 #define RTL8366RB_MAC_FORCE_CTRL_REG	0x0F11
 

@@ -835,6 +841,15 @@ static int rtl8366rb_setup(struct dsa_switch *ds)
 	if (ret)
 		return ret;
 
+	/* Isolate user ports */
+	for (i = 0; i < RTL8366RB_PORT_NUM_CPU; i++) {
+		ret = regmap_write(smi->map, RTL8366RB_PORT_ISO(i),
+				   RTL8366RB_PORT_ISO_EN |
+				   BIT(RTL8366RB_PORT_NUM_CPU + 1));
+		if (ret)
+			return ret;
+	}
+
 	/* Set up the "green ethernet" feature */
 	ret = rtl8366rb_jam_table(rtl8366rb_green_jam,
 				  ARRAY_SIZE(rtl8366rb_green_jam), smi, false);

@@ -963,10 +978,6 @@ static int rtl8366rb_setup(struct dsa_switch *ds)
 			return ret;
 	}
 
-	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");

@@ -977,8 +988,6 @@ static int rtl8366rb_setup(struct dsa_switch *ds)
 		return -ENODEV;
 	}
 
-	ds->configure_vlan_while_not_filtering = false;
-
 	return 0;
 }
 

@@ -1127,6 +1136,56 @@ rtl8366rb_port_disable(struct dsa_switch *ds, int port)
 	rb8366rb_set_port_led(smi, port, false);
 }
 
+static int
+rtl8366rb_port_bridge_join(struct dsa_switch *ds, int port,
+			   struct net_device *bridge)
+{
+	struct realtek_smi *smi = ds->priv;
+	unsigned int port_bitmap = 0;
+	int ret, i;
+
+	for (i = 0; i < RTL8366RB_PORT_NUM_CPU; i++) {
+		if (i == port)
+			continue;
+		if (dsa_to_port(ds, i)->bridge_dev != bridge)
+			continue;
+		ret = regmap_update_bits(smi->map, RTL8366RB_PORT_ISO(i),
+					 0, BIT(port + 1));
+		if (ret)
+			return ret;
+
+		port_bitmap |= BIT(i);
+	}
+
+	return regmap_update_bits(smi->map, RTL8366RB_PORT_ISO(port),
+				  0, port_bitmap << 1);
+}
+
+static int
+rtl8366rb_port_bridge_leave(struct dsa_switch *ds, int port,
+			    struct net_device *bridge)
+{
+	struct realtek_smi *smi = ds->priv;
+	unsigned int port_bitmap = 0;
+	int ret, i;
+
+	for (i = 0; i < RTL8366RB_PORT_NUM_CPU; i++) {
+		if (i == port)
+			continue;
+		if (dsa_to_port(ds, i)->bridge_dev != bridge)
+			continue;
+		ret = regmap_update_bits(smi->map, RTL8366RB_PORT_ISO(i),
+					 BIT(port + 1), 0);
+		if (ret)
+			return ret;
+
+		port_bitmap |= BIT(i);
+	}
+
+	return regmap_update_bits(smi->map, RTL8366RB_PORT_ISO(port),
+				  port_bitmap << 1, 0);
+}
+
 static int rtl8366rb_change_mtu(struct dsa_switch *ds, int port, int new_mtu)
 {
 	struct realtek_smi *smi = ds->priv;

@@ -1510,6 +1569,8 @@ static const struct dsa_switch_ops rtl8366rb_switch_ops = {
 	.get_strings = rtl8366_get_strings,
 	.get_ethtool_stats = rtl8366_get_ethtool_stats,
 	.get_sset_count = rtl8366_get_sset_count,
+	.port_bridge_join = rtl8366rb_port_bridge_join,
+	.port_bridge_leave = rtl8366rb_port_bridge_leave,
 	.port_vlan_filtering = rtl8366_vlan_filtering,
 	.port_vlan_add = rtl8366_vlan_add,
 	.port_vlan_del = rtl8366_vlan_del,

-- 
2.25.1

On Wed, Feb 24, 2021 at 7:12 AM DENG Qingfang [off-list ref] wrote:

Use port isolation registers to configure bridge offloading.
Remove the VLAN init, as we have proper CPU tag and bridge offloading
support now.

Signed-off-by: DENG Qingfang <dqfext@gmail.com>
---
This is not tested, as I don't have a RTL8366RB board. And I think there
is potential race condition in port_bridge_{join,leave}.

Compilation failed for me like this:

../drivers/net/dsa/rtl8366rb.c:1573:23: error: initialization of 'void
(*)(struct dsa_switch *, int,  struct net_device *)' from incompatible
pointer type 'int (*)(struct dsa_switch *, int,  struct net_device *)'
[-Werror=incompatible-pointer-types]
 1573 |  .port_bridge_leave = rtl8366rb_port_bridge_leave,
      |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
../drivers/net/dsa/rtl8366rb.c:1573:23: note: (near initialization for
'rtl8366rb_switch_ops.port_bridge_leave')

I fixed it like this:

diff --git a/drivers/net/dsa/rtl8366rb.c b/drivers/net/dsa/rtl8366rb.c
index e7abf846350d..0719fadadc3d 100644
--- a/drivers/net/dsa/rtl8366rb.c
+++ b/drivers/net/dsa/rtl8366rb.c

@@ -1161,7 +1161,7 @@ rtl8366rb_port_bridge_join(struct dsa_switch

*ds, int port,
                                  0, port_bitmap << 1);
 }

-static int
+static void
 rtl8366rb_port_bridge_leave(struct dsa_switch *ds, int port,
                            struct net_device *bridge)
 {

@@ -1176,14 +1176,17 @@ rtl8366rb_port_bridge_leave(struct dsa_switch

*ds, int port,
                        continue;
                ret = regmap_update_bits(smi->map, RTL8366RB_PORT_ISO(i),
                                         BIT(port + 1), 0);
-               if (ret)
-                       return ret;
+               if (ret) {
+                       dev_err(smi->dev, "failed to leave port %d
from bridge\n",
+                               port);
+                       return;
+               }

                port_bitmap |= BIT(i);
        }

-       return regmap_update_bits(smi->map, RTL8366RB_PORT_ISO(port),
-                                 port_bitmap << 1, 0);
+       regmap_update_bits(smi->map, RTL8366RB_PORT_ISO(port),
+                          port_bitmap << 1, 0);
 }

After this it works like a charm.

-       ret = rtl8366_init_vlan(smi);
-       if (ret)
-               return ret;

I suppose we can delete that confused VLAN set-up after this.

-       ds->configure_vlan_while_not_filtering = false;

This is default true not IIUC so we should be good!

With my minor changes:
Tested-by: Linus Walleij <redacted>

Yours,
Linus Walleij

On Wed, Feb 24, 2021 at 7:12 AM DENG Qingfang [off-list ref] wrote:

+/* Port isolation registers */
+#define RTL8366RB_PORT_ISO_BASE                0x0F08
+#define RTL8366RB_PORT_ISO(pnum)       (RTL8366RB_PORT_ISO_BASE + (pnum))
+#define RTL8366RB_PORT_ISO_EN          BIT(0)
+#define RTL8366RB_PORT_ISO_PORTS_MASK  GENMASK(7, 1)

BTW where did you find this register? It's not in any of my
vendor driver code dumps.

Curious!

Yours,
Linus Walleij

On Mon, Mar 1, 2021 at 9:55 PM Linus Walleij [off-list ref] wrote:

BTW where did you find this register? It's not in any of my
vendor driver code dumps.

DD-WRT
https://svn.dd-wrt.com/browser/src/linux/universal/linux-4.14/drivers/net/ethernet/ag7100/RTL8366RB_DRIVER/rtl8368s_reg.h#L581

Curious!

Yours,
Linus Walleij

On Mon, Mar 1, 2021 at 9:48 PM Linus Walleij [off-list ref] wrote:

With my minor changes:
Tested-by: Linus Walleij <redacted>

How about using a mutex lock in port_bridge_{join,leave} ?
In my opinion all functions that access multiple registers should be
synchronized.

Yours,
Linus Walleij

On Tue, Mar 2, 2021 at 4:58 AM DENG Qingfang [off-list ref] wrote:

On Mon, Mar 1, 2021 at 9:48 PM Linus Walleij [off-list ref] wrote:

quoted

With my minor changes:
Tested-by: Linus Walleij <redacted>

How about using a mutex lock in port_bridge_{join,leave} ?
In my opinion all functions that access multiple registers should be
synchronized.

That's one way, in some cases the framework (DSA) serialize
the accesses so I don't know if that already happens on a
higher level? Since it is accessed over a slow bus we should go
for mutex in that case indeed.

Yours,
Linus Walleij

On Tue, Mar 2, 2021 at 5:11 PM Vladimir Oltean [off-list ref] wrote:

On Tue, Mar 02, 2021 at 05:05:00PM +0100, Linus Walleij wrote:

quoted

On Tue, Mar 2, 2021 at 4:58 AM DENG Qingfang [off-list ref] wrote:

quoted

On Mon, Mar 1, 2021 at 9:48 PM Linus Walleij [off-list ref] wrote:

quoted

With my minor changes:
Tested-by: Linus Walleij <redacted>

How about using a mutex lock in port_bridge_{join,leave} ?
In my opinion all functions that access multiple registers should be
synchronized.

That's one way, in some cases the framework (DSA) serialize
the accesses so I don't know if that already happens on a
higher level? Since it is accessed over a slow bus we should go
for mutex in that case indeed.

DSA does not serialize this. The .port_bridge_join and
.port_bridge_leave calls are initiated from the NETDEV_CHANGEUPPER net
device event, which is called under rtnl_mutex (see call_netdevice_notifiers).
This is pretty fundamental and I don't think it will ever change.

However, if you still want to add an extra layer of locking (with code
paths that for some reason are not under the rtnl_mutex), then go ahead,
I suppose. It will be challenging to make sure they do something that
isn't snake oil, though.

Nah, just didn't know if was already in place.

I suggest Qingfang go with a driver-local mutex (it may already be needed in
more places).

Yours,
Linus Walleij

On Tue, Mar 02, 2021 at 05:05:00PM +0100, Linus Walleij wrote:

On Tue, Mar 2, 2021 at 4:58 AM DENG Qingfang [off-list ref] wrote:

quoted

On Mon, Mar 1, 2021 at 9:48 PM Linus Walleij [off-list ref] wrote:

quoted

With my minor changes:
Tested-by: Linus Walleij <redacted>

How about using a mutex lock in port_bridge_{join,leave} ?
In my opinion all functions that access multiple registers should be
synchronized.

That's one way, in some cases the framework (DSA) serialize
the accesses so I don't know if that already happens on a
higher level? Since it is accessed over a slow bus we should go
for mutex in that case indeed.

DSA does not serialize this. The .port_bridge_join and
.port_bridge_leave calls are initiated from the NETDEV_CHANGEUPPER net
device event, which is called under rtnl_mutex (see call_netdevice_notifiers).
This is pretty fundamental and I don't think it will ever change.

However, if you still want to add an extra layer of locking (with code
paths that for some reason are not under the rtnl_mutex), then go ahead,
I suppose. It will be challenging to make sure they do something that
isn't snake oil, though.

On 2/23/2021 10:12 PM, DENG Qingfang wrote:

If you have a configuration with ports that are part of a bridge with
VLAN filtering enabled, what happens to the standalone ports, are they a
member of a default VLAN entry still?
-- 
Florian