linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC net-next] net: dsa: rtl8366rb: support bridge offloading
@ 2021-02-24  6:12 DENG Qingfang
  2021-03-01 13:48 ` Linus Walleij
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: DENG Qingfang @ 2021-02-24  6:12 UTC (permalink / raw)
  To: Linus Walleij, Andrew Lunn, Vivien Didelot, Florian Fainelli,
	Vladimir Oltean, David S. Miller, Jakub Kicinski, Russell King,
	netdev, linux-kernel

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


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

* Re: [RFC net-next] net: dsa: rtl8366rb: support bridge offloading
  2021-02-24  6:12 [RFC net-next] net: dsa: rtl8366rb: support bridge offloading DENG Qingfang
@ 2021-03-01 13:48 ` Linus Walleij
  2021-03-02  3:58   ` DENG Qingfang
  2021-03-01 13:55 ` Linus Walleij
  2021-03-03  4:35 ` Florian Fainelli
  2 siblings, 1 reply; 9+ messages in thread
From: Linus Walleij @ 2021-03-01 13:48 UTC (permalink / raw)
  To: DENG Qingfang
  Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, Vladimir Oltean,
	David S. Miller, Jakub Kicinski, Russell King, netdev,
	linux-kernel

On Wed, Feb 24, 2021 at 7:12 AM DENG Qingfang <dqfext@gmail.com> 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 <linus.walleij@linaro.org>

Yours,
Linus Walleij

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

* Re: [RFC net-next] net: dsa: rtl8366rb: support bridge offloading
  2021-02-24  6:12 [RFC net-next] net: dsa: rtl8366rb: support bridge offloading DENG Qingfang
  2021-03-01 13:48 ` Linus Walleij
@ 2021-03-01 13:55 ` Linus Walleij
  2021-03-02  3:39   ` DENG Qingfang
  2021-03-03  4:35 ` Florian Fainelli
  2 siblings, 1 reply; 9+ messages in thread
From: Linus Walleij @ 2021-03-01 13:55 UTC (permalink / raw)
  To: DENG Qingfang
  Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, Vladimir Oltean,
	David S. Miller, Jakub Kicinski, Russell King, netdev,
	linux-kernel

On Wed, Feb 24, 2021 at 7:12 AM DENG Qingfang <dqfext@gmail.com> 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

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

* Re: [RFC net-next] net: dsa: rtl8366rb: support bridge offloading
  2021-03-01 13:55 ` Linus Walleij
@ 2021-03-02  3:39   ` DENG Qingfang
  0 siblings, 0 replies; 9+ messages in thread
From: DENG Qingfang @ 2021-03-02  3:39 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, Vladimir Oltean,
	David S. Miller, Jakub Kicinski, Russell King, netdev,
	linux-kernel

On Mon, Mar 1, 2021 at 9:55 PM Linus Walleij <linus.walleij@linaro.org> 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

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

* Re: [RFC net-next] net: dsa: rtl8366rb: support bridge offloading
  2021-03-01 13:48 ` Linus Walleij
@ 2021-03-02  3:58   ` DENG Qingfang
  2021-03-02 16:05     ` Linus Walleij
  0 siblings, 1 reply; 9+ messages in thread
From: DENG Qingfang @ 2021-03-02  3:58 UTC (permalink / raw)
  To: Linus Walleij
  Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, Vladimir Oltean,
	David S. Miller, Jakub Kicinski, Russell King, netdev,
	linux-kernel

On Mon, Mar 1, 2021 at 9:48 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> With my minor changes:
> Tested-by: Linus Walleij <linus.walleij@linaro.org>

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

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

* Re: [RFC net-next] net: dsa: rtl8366rb: support bridge offloading
  2021-03-02  3:58   ` DENG Qingfang
@ 2021-03-02 16:05     ` Linus Walleij
  2021-03-02 16:11       ` Vladimir Oltean
  0 siblings, 1 reply; 9+ messages in thread
From: Linus Walleij @ 2021-03-02 16:05 UTC (permalink / raw)
  To: DENG Qingfang
  Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, Vladimir Oltean,
	David S. Miller, Jakub Kicinski, Russell King, netdev,
	linux-kernel

On Tue, Mar 2, 2021 at 4:58 AM DENG Qingfang <dqfext@gmail.com> wrote:
> On Mon, Mar 1, 2021 at 9:48 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> > With my minor changes:
> > Tested-by: Linus Walleij <linus.walleij@linaro.org>
>
> 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

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

* Re: [RFC net-next] net: dsa: rtl8366rb: support bridge offloading
  2021-03-02 16:05     ` Linus Walleij
@ 2021-03-02 16:11       ` Vladimir Oltean
  2021-03-02 16:24         ` Linus Walleij
  0 siblings, 1 reply; 9+ messages in thread
From: Vladimir Oltean @ 2021-03-02 16:11 UTC (permalink / raw)
  To: Linus Walleij
  Cc: DENG Qingfang, Andrew Lunn, Vivien Didelot, Florian Fainelli,
	David S. Miller, Jakub Kicinski, Russell King, netdev,
	linux-kernel

On Tue, Mar 02, 2021 at 05:05:00PM +0100, Linus Walleij wrote:
> On Tue, Mar 2, 2021 at 4:58 AM DENG Qingfang <dqfext@gmail.com> wrote:
> > On Mon, Mar 1, 2021 at 9:48 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> > > With my minor changes:
> > > Tested-by: Linus Walleij <linus.walleij@linaro.org>
> >
> > 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.

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

* Re: [RFC net-next] net: dsa: rtl8366rb: support bridge offloading
  2021-03-02 16:11       ` Vladimir Oltean
@ 2021-03-02 16:24         ` Linus Walleij
  0 siblings, 0 replies; 9+ messages in thread
From: Linus Walleij @ 2021-03-02 16:24 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: DENG Qingfang, Andrew Lunn, Vivien Didelot, Florian Fainelli,
	David S. Miller, Jakub Kicinski, Russell King, netdev,
	linux-kernel

On Tue, Mar 2, 2021 at 5:11 PM Vladimir Oltean <olteanv@gmail.com> wrote:
> On Tue, Mar 02, 2021 at 05:05:00PM +0100, Linus Walleij wrote:
> > On Tue, Mar 2, 2021 at 4:58 AM DENG Qingfang <dqfext@gmail.com> wrote:
> > > On Mon, Mar 1, 2021 at 9:48 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> > > > With my minor changes:
> > > > Tested-by: Linus Walleij <linus.walleij@linaro.org>
> > >
> > > 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

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

* Re: [RFC net-next] net: dsa: rtl8366rb: support bridge offloading
  2021-02-24  6:12 [RFC net-next] net: dsa: rtl8366rb: support bridge offloading DENG Qingfang
  2021-03-01 13:48 ` Linus Walleij
  2021-03-01 13:55 ` Linus Walleij
@ 2021-03-03  4:35 ` Florian Fainelli
  2 siblings, 0 replies; 9+ messages in thread
From: Florian Fainelli @ 2021-03-03  4:35 UTC (permalink / raw)
  To: DENG Qingfang, Linus Walleij, Andrew Lunn, Vivien Didelot,
	Vladimir Oltean, David S. Miller, Jakub Kicinski, Russell King,
	netdev, linux-kernel



On 2/23/2021 10:12 PM, DENG Qingfang 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}.
> 
>  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;

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

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

end of thread, other threads:[~2021-03-03 11:56 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-24  6:12 [RFC net-next] net: dsa: rtl8366rb: support bridge offloading DENG Qingfang
2021-03-01 13:48 ` Linus Walleij
2021-03-02  3:58   ` DENG Qingfang
2021-03-02 16:05     ` Linus Walleij
2021-03-02 16:11       ` Vladimir Oltean
2021-03-02 16:24         ` Linus Walleij
2021-03-01 13:55 ` Linus Walleij
2021-03-02  3:39   ` DENG Qingfang
2021-03-03  4:35 ` Florian Fainelli

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).