* [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).