All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH net-next 0/4] Cross-chip bridging for disjoint DSA trees
@ 2020-04-29 16:19 Vladimir Oltean
  2020-04-29 16:19 ` [PATCH net-next 1/4] bridge: Allow enslaving DSA master network devices Vladimir Oltean
                   ` (3 more replies)
  0 siblings, 4 replies; 12+ messages in thread
From: Vladimir Oltean @ 2020-04-29 16:19 UTC (permalink / raw)
  To: andrew, f.fainelli, vivien.didelot, davem
  Cc: jiri, idosch, kuba, netdev, leoyang.li, nikolay

This series adds support for boards where DSA switches of multiple types
are cascaded together. Actually this type of setup was brought up before
on netdev, and it looks like utilizing disjoint trees is the way to go:

https://lkml.org/lkml/2019/7/7/225

The trouble with disjoint trees (prior to this patch series) is that only
bridging of ports within the same hardware switch can be offloaded.
After scratching my head for a while, it looks like the easiest way to
support hardware bridging between different DSA trees is to bridge their
DSA masters and extend the crosschip bridging operations.

I have given some thought to bridging the DSA masters with the slaves
themselves, but given the hardware topology described in the commit
message of patch 4/4, virtually any number (and combination) of bridges
(forwarding domains) can be created on top of those 3x4-port front-panel
switches. So it becomes a lot less obvious, when the front-panel ports
are enslaved to more than 1 bridge, which bridge should the DSA masters
be enslaved to.

So the least awkward approach was to just create a completely separate
bridge for the DSA masters, whose entire purpose is to permit hardware
forwarding between the discrete switches beneath it.

Florian Fainelli (1):
  bridge: Allow enslaving DSA master network devices

Vladimir Oltean (3):
  net: dsa: permit cross-chip bridging between all trees in the system
  net: dsa: introduce a dsa_switch_find function
  net: dsa: sja1105: implement cross-chip bridging operations

 drivers/net/dsa/mv88e6xxx/chip.c       |  16 +++-
 drivers/net/dsa/sja1105/sja1105_main.c | 122 +++++++++++++++++++++++++
 include/net/dsa.h                      |  11 ++-
 net/bridge/br_if.c                     |   4 +-
 net/bridge/br_input.c                  |   4 +-
 net/dsa/dsa2.c                         |  21 +++++
 net/dsa/dsa_priv.h                     |   1 +
 net/dsa/port.c                         |  23 ++++-
 net/dsa/switch.c                       |  21 +++--
 9 files changed, 203 insertions(+), 20 deletions(-)

-- 
2.17.1


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

* [PATCH net-next 1/4] bridge: Allow enslaving DSA master network devices
  2020-04-29 16:19 [PATCH net-next 0/4] Cross-chip bridging for disjoint DSA trees Vladimir Oltean
@ 2020-04-29 16:19 ` Vladimir Oltean
  2020-04-29 16:27   ` Nikolay Aleksandrov
  2020-04-29 16:19 ` [PATCH net-next 2/4] net: dsa: permit cross-chip bridging between all trees in the system Vladimir Oltean
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 12+ messages in thread
From: Vladimir Oltean @ 2020-04-29 16:19 UTC (permalink / raw)
  To: andrew, f.fainelli, vivien.didelot, davem
  Cc: jiri, idosch, kuba, netdev, leoyang.li, nikolay

From: Florian Fainelli <f.fainelli@gmail.com>

Commit 8db0a2ee2c63 ("net: bridge: reject DSA-enabled master netdevices
as bridge members") added a special check in br_if.c in order to check
for a DSA master network device with a tagging protocol configured. This
was done because back then, such devices, once enslaved in a bridge
would become inoperative and would not pass DSA tagged traffic anymore
due to br_handle_frame returning RX_HANDLER_CONSUMED.

But right now we have valid use cases which do require bridging of DSA
masters. One such example is when the DSA master ports are DSA switch
ports themselves (in a disjoint tree setup). This should be completely
equivalent, functionally speaking, from having multiple DSA switches
hanging off of the ports of a switchdev driver. So we should allow the
enslaving of DSA tagged master network devices.

Make br_handle_frame() return RX_HANDLER_PASS in order to call into the
DSA specific tagging protocol handlers, and lift the restriction from
br_add_if.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 net/bridge/br_if.c    | 4 +---
 net/bridge/br_input.c | 4 +++-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index ca685c0cdf95..e0fbdb855664 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -18,7 +18,6 @@
 #include <linux/rtnetlink.h>
 #include <linux/if_ether.h>
 #include <linux/slab.h>
-#include <net/dsa.h>
 #include <net/sock.h>
 #include <linux/if_vlan.h>
 #include <net/switchdev.h>
@@ -571,8 +570,7 @@ int br_add_if(struct net_bridge *br, struct net_device *dev,
 	 */
 	if ((dev->flags & IFF_LOOPBACK) ||
 	    dev->type != ARPHRD_ETHER || dev->addr_len != ETH_ALEN ||
-	    !is_valid_ether_addr(dev->dev_addr) ||
-	    netdev_uses_dsa(dev))
+	    !is_valid_ether_addr(dev->dev_addr))
 		return -EINVAL;
 
 	/* No bridging of bridges */
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index d5c34f36f0f4..396bc0c18cb5 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -17,6 +17,7 @@
 #endif
 #include <linux/neighbour.h>
 #include <net/arp.h>
+#include <net/dsa.h>
 #include <linux/export.h>
 #include <linux/rculist.h>
 #include "br_private.h"
@@ -263,7 +264,8 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
 	struct sk_buff *skb = *pskb;
 	const unsigned char *dest = eth_hdr(skb)->h_dest;
 
-	if (unlikely(skb->pkt_type == PACKET_LOOPBACK))
+	if (unlikely(skb->pkt_type == PACKET_LOOPBACK) ||
+	    netdev_uses_dsa(skb->dev))
 		return RX_HANDLER_PASS;
 
 	if (!is_valid_ether_addr(eth_hdr(skb)->h_source))
-- 
2.17.1


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

* [PATCH net-next 2/4] net: dsa: permit cross-chip bridging between all trees in the system
  2020-04-29 16:19 [PATCH net-next 0/4] Cross-chip bridging for disjoint DSA trees Vladimir Oltean
  2020-04-29 16:19 ` [PATCH net-next 1/4] bridge: Allow enslaving DSA master network devices Vladimir Oltean
@ 2020-04-29 16:19 ` Vladimir Oltean
  2020-04-29 16:19 ` [PATCH net-next 3/4] net: dsa: introduce a dsa_switch_find function Vladimir Oltean
  2020-04-29 16:19 ` [PATCH net-next 4/4] net: dsa: sja1105: implement cross-chip bridging operations Vladimir Oltean
  3 siblings, 0 replies; 12+ messages in thread
From: Vladimir Oltean @ 2020-04-29 16:19 UTC (permalink / raw)
  To: andrew, f.fainelli, vivien.didelot, davem
  Cc: jiri, idosch, kuba, netdev, leoyang.li, nikolay

From: Vladimir Oltean <vladimir.oltean@nxp.com>

One way of utilizing DSA is by cascading switches which do not all have
compatible taggers. Consider the following real-life topology:

      +---------------------------------------------------------------+
      | LS1028A                                                       |
      |               +------------------------------+                |
      |               |      DSA master for Felix    |                |
      |               |(internal ENETC port 2: eno2))|                |
      |  +------------+------------------------------+-------------+  |
      |  | Felix embedded L2 switch                                |  |
      |  |                                                         |  |
      |  | +--------------+   +--------------+   +--------------+  |  |
      |  | |DSA master for|   |DSA master for|   |DSA master for|  |  |
      |  | |  SJA1105 1   |   |  SJA1105 2   |   |  SJA1105 3   |  |  |
      |  | |(Felix port 1)|   |(Felix port 2)|   |(Felix port 3)|  |  |
      +--+-+--------------+---+--------------+---+--------------+--+--+

+-----------------------+ +-----------------------+ +-----------------------+
|   SJA1105 switch 1    | |   SJA1105 switch 2    | |   SJA1105 switch 3    |
+-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+
|sw1p0|sw1p1|sw1p2|sw1p3| |sw2p0|sw2p1|sw2p2|sw2p3| |sw3p0|sw3p1|sw3p2|sw3p3|
+-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+

The above can be described in the device tree as follows (obviously not
complete):

mscc_felix {
	dsa,member = <0 0>;
	ports {
		port@4 {
			ethernet = <&enetc_port2>;
		};
	};
};

sja1105_switch1 {
	dsa,member = <1 1>;
	ports {
		port@4 {
			ethernet = <&mscc_felix_port1>;
		};
	};
};

sja1105_switch2 {
	dsa,member = <2 2>;
	ports {
		port@4 {
			ethernet = <&mscc_felix_port2>;
		};
	};
};

sja1105_switch3 {
	dsa,member = <3 3>;
	ports {
		port@4 {
			ethernet = <&mscc_felix_port3>;
		};
	};
};

Basically we instantiate one DSA switch tree for every hardware switch
in the system, but we still give them globally unique switch IDs (will
come back to that later). Having 3 disjoint switch trees makes the
tagger drivers "just work", because net devices are registered for the
3 Felix DSA master ports, and they are also DSA slave ports to the ENETC
port. So packets received on the ENETC port are stripped of their
stacked DSA tags one by one.

Currently, hardware bridging between ports on the same sja1105 chip is
possible, but switching between sja1105 ports on different chips is
handled by the software bridge. This is fine, but we can do better.

In fact, the dsa_8021q tag used by sja1105 is compatible with cascading.
In other words, a sja1105 switch can correctly parse and route a packet
containing a dsa_8021q tag. So if we could enable hardware bridging on
the Felix DSA master ports, cross-chip bridging could be completely
offloaded.

Such as system would be used as follows:

ip link add dev br0 type bridge && ip link set dev br0 up
for port in sw0p0 sw0p1 sw0p2 sw0p3 \
	    sw1p0 sw1p1 sw1p2 sw1p3 \
	    sw2p0 sw2p1 sw2p2 sw2p3; do
	ip link set dev $port master br0
done

The above makes switching between ports on the same row be performed in
hardware, and between ports on different rows in software. Now assume
the Felix switch ports are called swp0, swp1, swp2. By running the
following extra commands:

ip link add dev br1 type bridge && ip link set dev br1 up
for port in swp0 swp1 swp2; do
	ip link set dev $port master br1
done

the CPU no longer sees packets which traverse sja1105 switch boundaries
and can be forwarded directly by Felix. The br1 bridge would not be used
for any sort of traffic termination.

For this to work, we need to give drivers an opportunity to listen for
bridging events on DSA trees other than their own, and pass that other
tree index as argument. I have made the assumption, for the moment, that
the other existing DSA notifiers don't need to be broadcast to other
trees. That assumption might turn out to be incorrect. But in the
meantime, introduce a dsa_broadcast function, similar in purpose to
dsa_port_notify, which is used only by the bridging notifiers.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 drivers/net/dsa/mv88e6xxx/chip.c | 16 ++++++++++++----
 include/net/dsa.h                | 10 ++++++----
 net/dsa/dsa_priv.h               |  1 +
 net/dsa/port.c                   | 23 +++++++++++++++++++++--
 net/dsa/switch.c                 | 21 +++++++++++++++------
 5 files changed, 55 insertions(+), 16 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index dd8a5666a584..9ecfbe0c4f6c 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2233,26 +2233,34 @@ static void mv88e6xxx_port_bridge_leave(struct dsa_switch *ds, int port,
 	mv88e6xxx_reg_unlock(chip);
 }
 
-static int mv88e6xxx_crosschip_bridge_join(struct dsa_switch *ds, int dev,
+static int mv88e6xxx_crosschip_bridge_join(struct dsa_switch *ds,
+					   int tree_index, int sw_index,
 					   int port, struct net_device *br)
 {
 	struct mv88e6xxx_chip *chip = ds->priv;
 	int err;
 
+	if (tree_index != ds->dst->index)
+		return 0;
+
 	mv88e6xxx_reg_lock(chip);
-	err = mv88e6xxx_pvt_map(chip, dev, port);
+	err = mv88e6xxx_pvt_map(chip, sw_index, port);
 	mv88e6xxx_reg_unlock(chip);
 
 	return err;
 }
 
-static void mv88e6xxx_crosschip_bridge_leave(struct dsa_switch *ds, int dev,
+static void mv88e6xxx_crosschip_bridge_leave(struct dsa_switch *ds,
+					     int tree_index, int sw_index,
 					     int port, struct net_device *br)
 {
 	struct mv88e6xxx_chip *chip = ds->priv;
 
+	if (tree_index != ds->dst->index)
+		return;
+
 	mv88e6xxx_reg_lock(chip);
-	if (mv88e6xxx_pvt_map(chip, dev, port))
+	if (mv88e6xxx_pvt_map(chip, sw_index, port))
 		dev_err(ds->dev, "failed to remap cross-chip Port VLAN\n");
 	mv88e6xxx_reg_unlock(chip);
 }
diff --git a/include/net/dsa.h b/include/net/dsa.h
index fb3f9222f2a1..b2111924c7ef 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -574,10 +574,12 @@ struct dsa_switch_ops {
 	/*
 	 * Cross-chip operations
 	 */
-	int	(*crosschip_bridge_join)(struct dsa_switch *ds, int sw_index,
-					 int port, struct net_device *br);
-	void	(*crosschip_bridge_leave)(struct dsa_switch *ds, int sw_index,
-					  int port, struct net_device *br);
+	int	(*crosschip_bridge_join)(struct dsa_switch *ds, int tree_index,
+					 int sw_index, int port,
+					 struct net_device *br);
+	void	(*crosschip_bridge_leave)(struct dsa_switch *ds, int tree_index,
+					  int sw_index, int port,
+					  struct net_device *br);
 
 	/*
 	 * PTP functionality
diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index 6d9a1ef65fa0..a1a0ae242012 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -35,6 +35,7 @@ struct dsa_notifier_ageing_time_info {
 /* DSA_NOTIFIER_BRIDGE_* */
 struct dsa_notifier_bridge_info {
 	struct net_device *br;
+	int tree_index;
 	int sw_index;
 	int port;
 };
diff --git a/net/dsa/port.c b/net/dsa/port.c
index a58fdd362574..ebc8d6cbd1d4 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -13,6 +13,23 @@
 
 #include "dsa_priv.h"
 
+static int dsa_broadcast(unsigned long e, void *v)
+{
+	struct dsa_switch_tree *dst;
+	int err = 0;
+
+	list_for_each_entry(dst, &dsa_tree_list, list) {
+		struct raw_notifier_head *nh = &dst->nh;
+
+		err = raw_notifier_call_chain(nh, e, v);
+		err = notifier_to_errno(err);
+		if (err)
+			break;
+	}
+
+	return err;
+}
+
 static int dsa_port_notify(const struct dsa_port *dp, unsigned long e, void *v)
 {
 	struct raw_notifier_head *nh = &dp->ds->dst->nh;
@@ -120,6 +137,7 @@ void dsa_port_disable(struct dsa_port *dp)
 int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br)
 {
 	struct dsa_notifier_bridge_info info = {
+		.tree_index = dp->ds->dst->index,
 		.sw_index = dp->ds->index,
 		.port = dp->index,
 		.br = br,
@@ -136,7 +154,7 @@ int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br)
 	 */
 	dp->bridge_dev = br;
 
-	err = dsa_port_notify(dp, DSA_NOTIFIER_BRIDGE_JOIN, &info);
+	err = dsa_broadcast(DSA_NOTIFIER_BRIDGE_JOIN, &info);
 
 	/* The bridging is rolled back on error */
 	if (err) {
@@ -150,6 +168,7 @@ int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br)
 void dsa_port_bridge_leave(struct dsa_port *dp, struct net_device *br)
 {
 	struct dsa_notifier_bridge_info info = {
+		.tree_index = dp->ds->dst->index,
 		.sw_index = dp->ds->index,
 		.port = dp->index,
 		.br = br,
@@ -161,7 +180,7 @@ void dsa_port_bridge_leave(struct dsa_port *dp, struct net_device *br)
 	 */
 	dp->bridge_dev = NULL;
 
-	err = dsa_port_notify(dp, DSA_NOTIFIER_BRIDGE_LEAVE, &info);
+	err = dsa_broadcast(DSA_NOTIFIER_BRIDGE_LEAVE, &info);
 	if (err)
 		pr_err("DSA: failed to notify DSA_NOTIFIER_BRIDGE_LEAVE\n");
 
diff --git a/net/dsa/switch.c b/net/dsa/switch.c
index f3c32ff552b3..86c8dc5c32a0 100644
--- a/net/dsa/switch.c
+++ b/net/dsa/switch.c
@@ -89,11 +89,16 @@ static int dsa_switch_mtu(struct dsa_switch *ds,
 static int dsa_switch_bridge_join(struct dsa_switch *ds,
 				  struct dsa_notifier_bridge_info *info)
 {
-	if (ds->index == info->sw_index && ds->ops->port_bridge_join)
+	struct dsa_switch_tree *dst = ds->dst;
+
+	if (dst->index == info->tree_index && ds->index == info->sw_index &&
+	    ds->ops->port_bridge_join)
 		return ds->ops->port_bridge_join(ds, info->port, info->br);
 
-	if (ds->index != info->sw_index && ds->ops->crosschip_bridge_join)
-		return ds->ops->crosschip_bridge_join(ds, info->sw_index,
+	if ((dst->index != info->tree_index || ds->index != info->sw_index) &&
+	    ds->ops->crosschip_bridge_join)
+		return ds->ops->crosschip_bridge_join(ds, info->tree_index,
+						      info->sw_index,
 						      info->port, info->br);
 
 	return 0;
@@ -103,13 +108,17 @@ static int dsa_switch_bridge_leave(struct dsa_switch *ds,
 				   struct dsa_notifier_bridge_info *info)
 {
 	bool unset_vlan_filtering = br_vlan_enabled(info->br);
+	struct dsa_switch_tree *dst = ds->dst;
 	int err, i;
 
-	if (ds->index == info->sw_index && ds->ops->port_bridge_leave)
+	if (dst->index == info->tree_index && ds->index == info->sw_index &&
+	    ds->ops->port_bridge_join)
 		ds->ops->port_bridge_leave(ds, info->port, info->br);
 
-	if (ds->index != info->sw_index && ds->ops->crosschip_bridge_leave)
-		ds->ops->crosschip_bridge_leave(ds, info->sw_index, info->port,
+	if ((dst->index != info->tree_index || ds->index != info->sw_index) &&
+	    ds->ops->crosschip_bridge_join)
+		ds->ops->crosschip_bridge_leave(ds, info->tree_index,
+						info->sw_index, info->port,
 						info->br);
 
 	/* If the bridge was vlan_filtering, the bridge core doesn't trigger an
-- 
2.17.1


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

* [PATCH net-next 3/4] net: dsa: introduce a dsa_switch_find function
  2020-04-29 16:19 [PATCH net-next 0/4] Cross-chip bridging for disjoint DSA trees Vladimir Oltean
  2020-04-29 16:19 ` [PATCH net-next 1/4] bridge: Allow enslaving DSA master network devices Vladimir Oltean
  2020-04-29 16:19 ` [PATCH net-next 2/4] net: dsa: permit cross-chip bridging between all trees in the system Vladimir Oltean
@ 2020-04-29 16:19 ` Vladimir Oltean
  2020-04-29 16:19 ` [PATCH net-next 4/4] net: dsa: sja1105: implement cross-chip bridging operations Vladimir Oltean
  3 siblings, 0 replies; 12+ messages in thread
From: Vladimir Oltean @ 2020-04-29 16:19 UTC (permalink / raw)
  To: andrew, f.fainelli, vivien.didelot, davem
  Cc: jiri, idosch, kuba, netdev, leoyang.li, nikolay

From: Vladimir Oltean <vladimir.oltean@nxp.com>

Somewhat similar to dsa_tree_find, dsa_switch_find returns a dsa_switch
structure pointer by searching for its tree index and switch index (the
parameters from dsa,member). To be used, for example, by drivers who
implement .crosschip_bridge_join and need a reference to the other
switch indicated to by the tree_index and sw_index arguments.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 include/net/dsa.h |  1 +
 net/dsa/dsa2.c    | 21 +++++++++++++++++++++
 2 files changed, 22 insertions(+)

diff --git a/include/net/dsa.h b/include/net/dsa.h
index b2111924c7ef..8a337387565a 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -671,6 +671,7 @@ static inline bool dsa_can_decode(const struct sk_buff *skb,
 
 void dsa_unregister_switch(struct dsa_switch *ds);
 int dsa_register_switch(struct dsa_switch *ds);
+struct dsa_switch *dsa_switch_find(int tree_index, int sw_index);
 #ifdef CONFIG_PM_SLEEP
 int dsa_switch_suspend(struct dsa_switch *ds);
 int dsa_switch_resume(struct dsa_switch *ds);
diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
index 9a271a58a41d..07e01b195975 100644
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@ -24,6 +24,27 @@ LIST_HEAD(dsa_tree_list);
 static const struct devlink_ops dsa_devlink_ops = {
 };
 
+struct dsa_switch *dsa_switch_find(int tree_index, int sw_index)
+{
+	struct dsa_switch_tree *dst;
+	struct dsa_port *dp;
+
+	list_for_each_entry(dst, &dsa_tree_list, list) {
+		if (dst->index != tree_index)
+			continue;
+
+		list_for_each_entry(dp, &dst->ports, list) {
+			if (dp->ds->index != sw_index)
+				continue;
+
+			return dp->ds;
+		}
+	}
+
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(dsa_switch_find);
+
 static struct dsa_switch_tree *dsa_tree_find(int index)
 {
 	struct dsa_switch_tree *dst;
-- 
2.17.1


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

* [PATCH net-next 4/4] net: dsa: sja1105: implement cross-chip bridging operations
  2020-04-29 16:19 [PATCH net-next 0/4] Cross-chip bridging for disjoint DSA trees Vladimir Oltean
                   ` (2 preceding siblings ...)
  2020-04-29 16:19 ` [PATCH net-next 3/4] net: dsa: introduce a dsa_switch_find function Vladimir Oltean
@ 2020-04-29 16:19 ` Vladimir Oltean
  3 siblings, 0 replies; 12+ messages in thread
From: Vladimir Oltean @ 2020-04-29 16:19 UTC (permalink / raw)
  To: andrew, f.fainelli, vivien.didelot, davem
  Cc: jiri, idosch, kuba, netdev, leoyang.li, nikolay

From: Vladimir Oltean <vladimir.oltean@nxp.com>

sja1105 uses dsa_8021q for DSA tagging, a format which is VLAN at heart
and which is compatible with cascading. A complete description of this
tagging format is in net/dsa/tag_8021q.c, but a quick summary is that
each external-facing port tags incoming frames with a unique pvid, and
this special VLAN is transmitted as tagged towards the inside of the
system, and as untagged towards the exterior. The tag encodes the switch
id and the source port index.

This means that cross-chip bridging for dsa_8021q only entails adding
the dsa_8021q pvids of one switch to the RX filter of the other
switches. Everything else falls naturally into place, as long as the
bottom-end of ports (the leaves in the tree) is comprised exclusively of
dsa_8021q-compatible (i.e. sja1105 switches). Otherwise, there would be
a chance that a front-panel switch transmits a packet tagged with a
dsa_8021q header, header which it wouldn't be able to remove, and which
would hence "leak" out.

The only use case I tested (due to lack of board availability) was when
the sja1105 switches are part of disjoint trees (however, this doesn't
change the fact that multiple sja1105 switches still need unique switch
identifiers in such a system). But in principle, even "true" single-tree
setups (with DSA links) should work just as fine, except for a small
change which I can't test: dsa_towards_port should be used instead of
dsa_upstream_port (I made the assumption that the routing port that any
sja1105 should use towards its neighbours is the CPU port. That might
not hold true in other setups).

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 drivers/net/dsa/sja1105/sja1105_main.c | 122 +++++++++++++++++++++++++
 1 file changed, 122 insertions(+)

diff --git a/drivers/net/dsa/sja1105/sja1105_main.c b/drivers/net/dsa/sja1105/sja1105_main.c
index 472f4eb20c49..32a05a2424a3 100644
--- a/drivers/net/dsa/sja1105/sja1105_main.c
+++ b/drivers/net/dsa/sja1105/sja1105_main.c
@@ -25,6 +25,8 @@
 #include "sja1105_sgmii.h"
 #include "sja1105_tas.h"
 
+static const struct dsa_switch_ops sja1105_switch_ops;
+
 static void sja1105_hw_reset(struct gpio_desc *gpio, unsigned int pulse_len,
 			     unsigned int startup_delay)
 {
@@ -1934,6 +1936,124 @@ static int sja1105_vlan_del(struct dsa_switch *ds, int port,
 	return 0;
 }
 
+static int sja1105_crosschip_bridge_member(struct dsa_switch *ds,
+					   int tree_index, int sw_index,
+					   int other_port,
+					   struct net_device *br, bool enabled)
+{
+	struct dsa_switch *other_ds = dsa_switch_find(tree_index, sw_index);
+	struct sja1105_private *priv = ds->priv;
+	struct sja1105_private *other_priv;
+	u16 rx_vid, other_rx_vid;
+	int cpu = -1, other_cpu;
+	int port, rc;
+
+	if (other_ds->ops != &sja1105_switch_ops)
+		return 0;
+
+	other_cpu = dsa_upstream_port(other_ds, other_port);
+	other_priv = other_ds->priv;
+
+	/* Make traffic from all local ports enslaved to @br be received
+	 * by @other_ds. This means that our @rx_vid needs to be installed
+	 * on @other_ds's CPU port and user ports. The user ports should be
+	 * egress-untagged so that the can pop the dsa_8021q VLAN. But the
+	 * @other_cpu can be either egress-tagged or untagged: it doesn't
+	 * matter, since it should never egress a frame having our @rx_vid.
+	 */
+	for (port = 0; port < SJA1105_NUM_PORTS; port++) {
+		if (!dsa_is_user_port(ds, port))
+			continue;
+		if (dsa_to_port(ds, port)->bridge_dev != br)
+			continue;
+
+		cpu = dsa_upstream_port(ds, port);
+
+		rx_vid = dsa_8021q_rx_vid(ds, port);
+
+		/* The VLANs on @other_cpu port should be refcounted, because
+		 * we don't want to remove our @rx_vid just yet when a single
+		 * remote port leaves. But that's tricky to implement, so just
+		 * keep it simple and leave the VLANs installed on the CPU
+		 * ports when leaving. Forwarding will still be denied, as it
+		 * should be, because the @rx_vid has been removed from the
+		 * remote switch's external port.
+		 */
+		if (enabled) {
+			/* @rx_vid of local @ds port @port goes to @other_cpu
+			 * of @other_ds
+			 */
+			rc = sja1105_vlan_apply(other_priv, other_cpu, rx_vid,
+						enabled, false);
+			if (rc < 0)
+				return rc;
+		}
+
+		/* @rx_vid of local @ds port @port goes to @other_port of
+		 * @other_ds
+		 */
+		rc = sja1105_vlan_apply(other_priv, other_port,
+					rx_vid, enabled, true);
+		if (rc < 0)
+			return rc;
+	}
+
+	/* Shorthand way of saying that we had no ports enslaved to @br. Also a
+	 * convenient way of getting a reference to the CPU port via
+	 * dsa_upstream_port(), which needs a valid user port as argument.
+	 */
+	if (cpu == -1)
+		return 0;
+
+	/* Make traffic from the remote @other_ds switch's @other_port be
+	 * accepted by the local @ds. This means that its @rx_vid needs to be
+	 * installed on our local CPU port as well as local ports that are
+	 * members of @br.
+	 */
+	other_rx_vid = dsa_8021q_rx_vid(other_ds, other_port);
+
+	for (port = 0; port < SJA1105_NUM_PORTS; port++) {
+		if (!dsa_is_user_port(ds, port))
+			continue;
+		if (dsa_to_port(ds, port)->bridge_dev != br)
+			continue;
+
+		/* @other_rx_vid of @other_ds port @other_port goes to port
+		 * @port of local @ds.
+		 */
+		rc = sja1105_vlan_apply(priv, port, other_rx_vid, enabled,
+					true);
+		if (rc < 0)
+			return rc;
+	}
+
+	/* The comment above regarding VLAN refcounting applies here too */
+	if (!enabled)
+		return 0;
+
+	/* @other_rx_vid of @other_ds port @other_port goes to port @cpu of
+	 * local @ds
+	 */
+	return sja1105_vlan_apply(priv, cpu, other_rx_vid, enabled, false);
+}
+
+static int sja1105_crosschip_bridge_join(struct dsa_switch *ds,
+					 int tree_index, int sw_index,
+					 int other_port, struct net_device *br)
+{
+	return sja1105_crosschip_bridge_member(ds, tree_index, sw_index,
+					       other_port, br, true);
+}
+
+static void sja1105_crosschip_bridge_leave(struct dsa_switch *ds,
+					   int tree_index, int sw_index,
+					   int other_port,
+					   struct net_device *br)
+{
+	sja1105_crosschip_bridge_member(ds, tree_index, sw_index, other_port,
+					br, false);
+}
+
 /* The programming model for the SJA1105 switch is "all-at-once" via static
  * configuration tables. Some of these can be dynamically modified at runtime,
  * but not the xMII mode parameters table.
@@ -2359,6 +2479,8 @@ static const struct dsa_switch_ops sja1105_switch_ops = {
 	.port_policer_del	= sja1105_port_policer_del,
 	.cls_flower_add		= sja1105_cls_flower_add,
 	.cls_flower_del		= sja1105_cls_flower_del,
+	.crosschip_bridge_join	= sja1105_crosschip_bridge_join,
+	.crosschip_bridge_leave	= sja1105_crosschip_bridge_leave,
 };
 
 static int sja1105_check_device_id(struct sja1105_private *priv)
-- 
2.17.1


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

* Re: [PATCH net-next 1/4] bridge: Allow enslaving DSA master network devices
  2020-04-29 16:19 ` [PATCH net-next 1/4] bridge: Allow enslaving DSA master network devices Vladimir Oltean
@ 2020-04-29 16:27   ` Nikolay Aleksandrov
  2020-04-29 16:33     ` Nikolay Aleksandrov
  0 siblings, 1 reply; 12+ messages in thread
From: Nikolay Aleksandrov @ 2020-04-29 16:27 UTC (permalink / raw)
  To: Vladimir Oltean, andrew, f.fainelli, vivien.didelot, davem
  Cc: jiri, idosch, kuba, netdev, leoyang.li

On 29/04/2020 19:19, Vladimir Oltean wrote:
> From: Florian Fainelli <f.fainelli@gmail.com>
> 
> Commit 8db0a2ee2c63 ("net: bridge: reject DSA-enabled master netdevices
> as bridge members") added a special check in br_if.c in order to check
> for a DSA master network device with a tagging protocol configured. This
> was done because back then, such devices, once enslaved in a bridge
> would become inoperative and would not pass DSA tagged traffic anymore
> due to br_handle_frame returning RX_HANDLER_CONSUMED.
> 
> But right now we have valid use cases which do require bridging of DSA
> masters. One such example is when the DSA master ports are DSA switch
> ports themselves (in a disjoint tree setup). This should be completely
> equivalent, functionally speaking, from having multiple DSA switches
> hanging off of the ports of a switchdev driver. So we should allow the
> enslaving of DSA tagged master network devices.
> 
> Make br_handle_frame() return RX_HANDLER_PASS in order to call into the
> DSA specific tagging protocol handlers, and lift the restriction from
> br_add_if.
> 
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
>  net/bridge/br_if.c    | 4 +---
>  net/bridge/br_input.c | 4 +++-
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
> index ca685c0cdf95..e0fbdb855664 100644
> --- a/net/bridge/br_if.c
> +++ b/net/bridge/br_if.c
> @@ -18,7 +18,6 @@
>  #include <linux/rtnetlink.h>
>  #include <linux/if_ether.h>
>  #include <linux/slab.h>
> -#include <net/dsa.h>
>  #include <net/sock.h>
>  #include <linux/if_vlan.h>
>  #include <net/switchdev.h>
> @@ -571,8 +570,7 @@ int br_add_if(struct net_bridge *br, struct net_device *dev,
>  	 */
>  	if ((dev->flags & IFF_LOOPBACK) ||
>  	    dev->type != ARPHRD_ETHER || dev->addr_len != ETH_ALEN ||
> -	    !is_valid_ether_addr(dev->dev_addr) ||
> -	    netdev_uses_dsa(dev))
> +	    !is_valid_ether_addr(dev->dev_addr))
>  		return -EINVAL;
>  
>  	/* No bridging of bridges */
> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> index d5c34f36f0f4..396bc0c18cb5 100644
> --- a/net/bridge/br_input.c
> +++ b/net/bridge/br_input.c
> @@ -17,6 +17,7 @@
>  #endif
>  #include <linux/neighbour.h>
>  #include <net/arp.h>
> +#include <net/dsa.h>
>  #include <linux/export.h>
>  #include <linux/rculist.h>
>  #include "br_private.h"
> @@ -263,7 +264,8 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
>  	struct sk_buff *skb = *pskb;
>  	const unsigned char *dest = eth_hdr(skb)->h_dest;
>  
> -	if (unlikely(skb->pkt_type == PACKET_LOOPBACK))
> +	if (unlikely(skb->pkt_type == PACKET_LOOPBACK) ||
> +	    netdev_uses_dsa(skb->dev))
>  		return RX_HANDLER_PASS;
>  
>  	if (!is_valid_ether_addr(eth_hdr(skb)->h_source))
> 

Yet another test in fast-path for all packets.
Since br_handle_frame will not be executed at all for such devices I'd suggest
to look into a scheme that avoid installing rx_handler and thus prevents br_handle_frame
to be called in the frist place. In case that is not possible then we can discuss adding
one more test in fast-path.

Actually you can just add a dummy rx_handler that simply returns RX_HANDLER_PASS for
these devices and keep rx_handler_data so all br_port_get_* will continue working.

Thanks,
 Nik





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

* Re: [PATCH net-next 1/4] bridge: Allow enslaving DSA master network devices
  2020-04-29 16:27   ` Nikolay Aleksandrov
@ 2020-04-29 16:33     ` Nikolay Aleksandrov
  2020-04-30 17:50       ` Vladimir Oltean
  0 siblings, 1 reply; 12+ messages in thread
From: Nikolay Aleksandrov @ 2020-04-29 16:33 UTC (permalink / raw)
  To: Vladimir Oltean, andrew, f.fainelli, vivien.didelot, davem
  Cc: jiri, idosch, kuba, netdev, leoyang.li, Roopa Prabhu

+CC Roopa

On 29/04/2020 19:27, Nikolay Aleksandrov wrote:
> On 29/04/2020 19:19, Vladimir Oltean wrote:
>> From: Florian Fainelli <f.fainelli@gmail.com>
>>
>> Commit 8db0a2ee2c63 ("net: bridge: reject DSA-enabled master netdevices
>> as bridge members") added a special check in br_if.c in order to check
>> for a DSA master network device with a tagging protocol configured. This
>> was done because back then, such devices, once enslaved in a bridge
>> would become inoperative and would not pass DSA tagged traffic anymore
>> due to br_handle_frame returning RX_HANDLER_CONSUMED.
>>
>> But right now we have valid use cases which do require bridging of DSA
>> masters. One such example is when the DSA master ports are DSA switch
>> ports themselves (in a disjoint tree setup). This should be completely
>> equivalent, functionally speaking, from having multiple DSA switches
>> hanging off of the ports of a switchdev driver. So we should allow the
>> enslaving of DSA tagged master network devices.
>>
>> Make br_handle_frame() return RX_HANDLER_PASS in order to call into the
>> DSA specific tagging protocol handlers, and lift the restriction from
>> br_add_if.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
>> ---
>>  net/bridge/br_if.c    | 4 +---
>>  net/bridge/br_input.c | 4 +++-
>>  2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
>> index ca685c0cdf95..e0fbdb855664 100644
>> --- a/net/bridge/br_if.c
>> +++ b/net/bridge/br_if.c
>> @@ -18,7 +18,6 @@
>>  #include <linux/rtnetlink.h>
>>  #include <linux/if_ether.h>
>>  #include <linux/slab.h>
>> -#include <net/dsa.h>
>>  #include <net/sock.h>
>>  #include <linux/if_vlan.h>
>>  #include <net/switchdev.h>
>> @@ -571,8 +570,7 @@ int br_add_if(struct net_bridge *br, struct net_device *dev,
>>  	 */
>>  	if ((dev->flags & IFF_LOOPBACK) ||
>>  	    dev->type != ARPHRD_ETHER || dev->addr_len != ETH_ALEN ||
>> -	    !is_valid_ether_addr(dev->dev_addr) ||
>> -	    netdev_uses_dsa(dev))
>> +	    !is_valid_ether_addr(dev->dev_addr))
>>  		return -EINVAL;
>>  
>>  	/* No bridging of bridges */
>> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
>> index d5c34f36f0f4..396bc0c18cb5 100644
>> --- a/net/bridge/br_input.c
>> +++ b/net/bridge/br_input.c
>> @@ -17,6 +17,7 @@
>>  #endif
>>  #include <linux/neighbour.h>
>>  #include <net/arp.h>
>> +#include <net/dsa.h>
>>  #include <linux/export.h>
>>  #include <linux/rculist.h>
>>  #include "br_private.h"
>> @@ -263,7 +264,8 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
>>  	struct sk_buff *skb = *pskb;
>>  	const unsigned char *dest = eth_hdr(skb)->h_dest;
>>  
>> -	if (unlikely(skb->pkt_type == PACKET_LOOPBACK))
>> +	if (unlikely(skb->pkt_type == PACKET_LOOPBACK) ||
>> +	    netdev_uses_dsa(skb->dev))
>>  		return RX_HANDLER_PASS;
>>  
>>  	if (!is_valid_ether_addr(eth_hdr(skb)->h_source))
>>
> 
> Yet another test in fast-path for all packets.
> Since br_handle_frame will not be executed at all for such devices I'd suggest
> to look into a scheme that avoid installing rx_handler and thus prevents br_handle_frame
> to be called in the frist place. In case that is not possible then we can discuss adding
> one more test in fast-path.
> 
> Actually you can just add a dummy rx_handler that simply returns RX_HANDLER_PASS for
> these devices and keep rx_handler_data so all br_port_get_* will continue working.
> 
> Thanks,
>  Nik
> 
> 
> 
> 


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

* Re: [PATCH net-next 1/4] bridge: Allow enslaving DSA master network devices
  2020-04-29 16:33     ` Nikolay Aleksandrov
@ 2020-04-30 17:50       ` Vladimir Oltean
  2020-04-30 17:54         ` Vladimir Oltean
                           ` (2 more replies)
  0 siblings, 3 replies; 12+ messages in thread
From: Vladimir Oltean @ 2020-04-30 17:50 UTC (permalink / raw)
  To: Nikolay Aleksandrov
  Cc: Andrew Lunn, Florian Fainelli, Vivien Didelot, David S. Miller,
	Jiri Pirko, Ido Schimmel, Jakub Kicinski, netdev, Li Yang,
	Roopa Prabhu

Hi Nikolay, Roopa,

On Wed, 29 Apr 2020 at 19:33, Nikolay Aleksandrov
<nikolay@cumulusnetworks.com> wrote:
>
> +CC Roopa
>
> On 29/04/2020 19:27, Nikolay Aleksandrov wrote:
> > On 29/04/2020 19:19, Vladimir Oltean wrote:
> >> From: Florian Fainelli <f.fainelli@gmail.com>
> >>
> >> Commit 8db0a2ee2c63 ("net: bridge: reject DSA-enabled master netdevices
> >> as bridge members") added a special check in br_if.c in order to check
> >> for a DSA master network device with a tagging protocol configured. This
> >> was done because back then, such devices, once enslaved in a bridge
> >> would become inoperative and would not pass DSA tagged traffic anymore
> >> due to br_handle_frame returning RX_HANDLER_CONSUMED.
> >>
> >> But right now we have valid use cases which do require bridging of DSA
> >> masters. One such example is when the DSA master ports are DSA switch
> >> ports themselves (in a disjoint tree setup). This should be completely
> >> equivalent, functionally speaking, from having multiple DSA switches
> >> hanging off of the ports of a switchdev driver. So we should allow the
> >> enslaving of DSA tagged master network devices.
> >>
> >> Make br_handle_frame() return RX_HANDLER_PASS in order to call into the
> >> DSA specific tagging protocol handlers, and lift the restriction from
> >> br_add_if.
> >>
> >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> >> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> >> ---
> >>  net/bridge/br_if.c    | 4 +---
> >>  net/bridge/br_input.c | 4 +++-
> >>  2 files changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
> >> index ca685c0cdf95..e0fbdb855664 100644
> >> --- a/net/bridge/br_if.c
> >> +++ b/net/bridge/br_if.c
> >> @@ -18,7 +18,6 @@
> >>  #include <linux/rtnetlink.h>
> >>  #include <linux/if_ether.h>
> >>  #include <linux/slab.h>
> >> -#include <net/dsa.h>
> >>  #include <net/sock.h>
> >>  #include <linux/if_vlan.h>
> >>  #include <net/switchdev.h>
> >> @@ -571,8 +570,7 @@ int br_add_if(struct net_bridge *br, struct net_device *dev,
> >>       */
> >>      if ((dev->flags & IFF_LOOPBACK) ||
> >>          dev->type != ARPHRD_ETHER || dev->addr_len != ETH_ALEN ||
> >> -        !is_valid_ether_addr(dev->dev_addr) ||
> >> -        netdev_uses_dsa(dev))
> >> +        !is_valid_ether_addr(dev->dev_addr))
> >>              return -EINVAL;
> >>
> >>      /* No bridging of bridges */
> >> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> >> index d5c34f36f0f4..396bc0c18cb5 100644
> >> --- a/net/bridge/br_input.c
> >> +++ b/net/bridge/br_input.c
> >> @@ -17,6 +17,7 @@
> >>  #endif
> >>  #include <linux/neighbour.h>
> >>  #include <net/arp.h>
> >> +#include <net/dsa.h>
> >>  #include <linux/export.h>
> >>  #include <linux/rculist.h>
> >>  #include "br_private.h"
> >> @@ -263,7 +264,8 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
> >>      struct sk_buff *skb = *pskb;
> >>      const unsigned char *dest = eth_hdr(skb)->h_dest;
> >>
> >> -    if (unlikely(skb->pkt_type == PACKET_LOOPBACK))
> >> +    if (unlikely(skb->pkt_type == PACKET_LOOPBACK) ||
> >> +        netdev_uses_dsa(skb->dev))
> >>              return RX_HANDLER_PASS;
> >>
> >>      if (!is_valid_ether_addr(eth_hdr(skb)->h_source))
> >>
> >
> > Yet another test in fast-path for all packets.
> > Since br_handle_frame will not be executed at all for such devices I'd suggest
> > to look into a scheme that avoid installing rx_handler and thus prevents br_handle_frame
> > to be called in the frist place. In case that is not possible then we can discuss adding
> > one more test in fast-path.
> >
> > Actually you can just add a dummy rx_handler that simply returns RX_HANDLER_PASS for
> > these devices and keep rx_handler_data so all br_port_get_* will continue working.
> >
> > Thanks,
> >  Nik
> >

Actually both of those are problematic, since br_port_get_check_rcu
and br_port_get_check_rtnl check for the rx_handler pointer against
br_handle_frame.
Actually a plain old revert of 8db0a2ee2c63 works just fine for what I
need it to, not sure if there's any point in making this any more
complicated than that.
What do you think?

Thanks,
-Vladimir

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

* Re: [PATCH net-next 1/4] bridge: Allow enslaving DSA master network devices
  2020-04-30 17:50       ` Vladimir Oltean
@ 2020-04-30 17:54         ` Vladimir Oltean
  2020-04-30 17:55         ` Nikolay Aleksandrov
  2020-04-30 17:56         ` Florian Fainelli
  2 siblings, 0 replies; 12+ messages in thread
From: Vladimir Oltean @ 2020-04-30 17:54 UTC (permalink / raw)
  To: Nikolay Aleksandrov
  Cc: Andrew Lunn, Florian Fainelli, Vivien Didelot, David S. Miller,
	Jiri Pirko, Ido Schimmel, Jakub Kicinski, netdev, Li Yang,
	Roopa Prabhu

On Thu, 30 Apr 2020 at 20:50, Vladimir Oltean <olteanv@gmail.com> wrote:
>
> Hi Nikolay, Roopa,
>
> On Wed, 29 Apr 2020 at 19:33, Nikolay Aleksandrov
> <nikolay@cumulusnetworks.com> wrote:
> >
> > +CC Roopa
> >
> > On 29/04/2020 19:27, Nikolay Aleksandrov wrote:
> > > On 29/04/2020 19:19, Vladimir Oltean wrote:
> > >> From: Florian Fainelli <f.fainelli@gmail.com>
> > >>
> > >> Commit 8db0a2ee2c63 ("net: bridge: reject DSA-enabled master netdevices
> > >> as bridge members") added a special check in br_if.c in order to check
> > >> for a DSA master network device with a tagging protocol configured. This
> > >> was done because back then, such devices, once enslaved in a bridge
> > >> would become inoperative and would not pass DSA tagged traffic anymore
> > >> due to br_handle_frame returning RX_HANDLER_CONSUMED.
> > >>
> > >> But right now we have valid use cases which do require bridging of DSA
> > >> masters. One such example is when the DSA master ports are DSA switch
> > >> ports themselves (in a disjoint tree setup). This should be completely
> > >> equivalent, functionally speaking, from having multiple DSA switches
> > >> hanging off of the ports of a switchdev driver. So we should allow the
> > >> enslaving of DSA tagged master network devices.
> > >>
> > >> Make br_handle_frame() return RX_HANDLER_PASS in order to call into the
> > >> DSA specific tagging protocol handlers, and lift the restriction from
> > >> br_add_if.
> > >>
> > >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> > >> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > >> ---
> > >>  net/bridge/br_if.c    | 4 +---
> > >>  net/bridge/br_input.c | 4 +++-
> > >>  2 files changed, 4 insertions(+), 4 deletions(-)
> > >>
> > >> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
> > >> index ca685c0cdf95..e0fbdb855664 100644
> > >> --- a/net/bridge/br_if.c
> > >> +++ b/net/bridge/br_if.c
> > >> @@ -18,7 +18,6 @@
> > >>  #include <linux/rtnetlink.h>
> > >>  #include <linux/if_ether.h>
> > >>  #include <linux/slab.h>
> > >> -#include <net/dsa.h>
> > >>  #include <net/sock.h>
> > >>  #include <linux/if_vlan.h>
> > >>  #include <net/switchdev.h>
> > >> @@ -571,8 +570,7 @@ int br_add_if(struct net_bridge *br, struct net_device *dev,
> > >>       */
> > >>      if ((dev->flags & IFF_LOOPBACK) ||
> > >>          dev->type != ARPHRD_ETHER || dev->addr_len != ETH_ALEN ||
> > >> -        !is_valid_ether_addr(dev->dev_addr) ||
> > >> -        netdev_uses_dsa(dev))
> > >> +        !is_valid_ether_addr(dev->dev_addr))
> > >>              return -EINVAL;
> > >>
> > >>      /* No bridging of bridges */
> > >> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> > >> index d5c34f36f0f4..396bc0c18cb5 100644
> > >> --- a/net/bridge/br_input.c
> > >> +++ b/net/bridge/br_input.c
> > >> @@ -17,6 +17,7 @@
> > >>  #endif
> > >>  #include <linux/neighbour.h>
> > >>  #include <net/arp.h>
> > >> +#include <net/dsa.h>
> > >>  #include <linux/export.h>
> > >>  #include <linux/rculist.h>
> > >>  #include "br_private.h"
> > >> @@ -263,7 +264,8 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
> > >>      struct sk_buff *skb = *pskb;
> > >>      const unsigned char *dest = eth_hdr(skb)->h_dest;
> > >>
> > >> -    if (unlikely(skb->pkt_type == PACKET_LOOPBACK))
> > >> +    if (unlikely(skb->pkt_type == PACKET_LOOPBACK) ||
> > >> +        netdev_uses_dsa(skb->dev))
> > >>              return RX_HANDLER_PASS;
> > >>
> > >>      if (!is_valid_ether_addr(eth_hdr(skb)->h_source))
> > >>
> > >
> > > Yet another test in fast-path for all packets.
> > > Since br_handle_frame will not be executed at all for such devices I'd suggest
> > > to look into a scheme that avoid installing rx_handler and thus prevents br_handle_frame
> > > to be called in the frist place. In case that is not possible then we can discuss adding
> > > one more test in fast-path.
> > >
> > > Actually you can just add a dummy rx_handler that simply returns RX_HANDLER_PASS for
> > > these devices and keep rx_handler_data so all br_port_get_* will continue working.
> > >
> > > Thanks,
> > >  Nik
> > >
>
> Actually both of those are problematic, since br_port_get_check_rcu
> and br_port_get_check_rtnl check for the rx_handler pointer against
> br_handle_frame.
> Actually a plain old revert of 8db0a2ee2c63 works just fine for what I
> need it to, not sure if there's any point in making this any more
> complicated than that.
> What do you think?
>
> Thanks,
> -Vladimir

I spoke way too soon, I should have tested before. Of course the plain
revert is not enough.

-Vladimir

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

* Re: [PATCH net-next 1/4] bridge: Allow enslaving DSA master network devices
  2020-04-30 17:50       ` Vladimir Oltean
  2020-04-30 17:54         ` Vladimir Oltean
@ 2020-04-30 17:55         ` Nikolay Aleksandrov
  2020-04-30 18:05           ` Nikolay Aleksandrov
  2020-04-30 17:56         ` Florian Fainelli
  2 siblings, 1 reply; 12+ messages in thread
From: Nikolay Aleksandrov @ 2020-04-30 17:55 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: Andrew Lunn, Florian Fainelli, Vivien Didelot, David S. Miller,
	Jiri Pirko, Ido Schimmel, Jakub Kicinski, netdev, Li Yang,
	Roopa Prabhu

On 30/04/2020 20:50, Vladimir Oltean wrote:
> Hi Nikolay, Roopa,
> 
> On Wed, 29 Apr 2020 at 19:33, Nikolay Aleksandrov
> <nikolay@cumulusnetworks.com> wrote:
>>
>> +CC Roopa
>>
>> On 29/04/2020 19:27, Nikolay Aleksandrov wrote:
>>> On 29/04/2020 19:19, Vladimir Oltean wrote:
>>>> From: Florian Fainelli <f.fainelli@gmail.com>
>>>>
>>>> Commit 8db0a2ee2c63 ("net: bridge: reject DSA-enabled master netdevices
>>>> as bridge members") added a special check in br_if.c in order to check
>>>> for a DSA master network device with a tagging protocol configured. This
>>>> was done because back then, such devices, once enslaved in a bridge
>>>> would become inoperative and would not pass DSA tagged traffic anymore
>>>> due to br_handle_frame returning RX_HANDLER_CONSUMED.
>>>>
>>>> But right now we have valid use cases which do require bridging of DSA
>>>> masters. One such example is when the DSA master ports are DSA switch
>>>> ports themselves (in a disjoint tree setup). This should be completely
>>>> equivalent, functionally speaking, from having multiple DSA switches
>>>> hanging off of the ports of a switchdev driver. So we should allow the
>>>> enslaving of DSA tagged master network devices.
>>>>
>>>> Make br_handle_frame() return RX_HANDLER_PASS in order to call into the
>>>> DSA specific tagging protocol handlers, and lift the restriction from
>>>> br_add_if.
>>>>
>>>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>>>> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
>>>> ---
>>>>  net/bridge/br_if.c    | 4 +---
>>>>  net/bridge/br_input.c | 4 +++-
>>>>  2 files changed, 4 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
>>>> index ca685c0cdf95..e0fbdb855664 100644
>>>> --- a/net/bridge/br_if.c
>>>> +++ b/net/bridge/br_if.c
>>>> @@ -18,7 +18,6 @@
>>>>  #include <linux/rtnetlink.h>
>>>>  #include <linux/if_ether.h>
>>>>  #include <linux/slab.h>
>>>> -#include <net/dsa.h>
>>>>  #include <net/sock.h>
>>>>  #include <linux/if_vlan.h>
>>>>  #include <net/switchdev.h>
>>>> @@ -571,8 +570,7 @@ int br_add_if(struct net_bridge *br, struct net_device *dev,
>>>>       */
>>>>      if ((dev->flags & IFF_LOOPBACK) ||
>>>>          dev->type != ARPHRD_ETHER || dev->addr_len != ETH_ALEN ||
>>>> -        !is_valid_ether_addr(dev->dev_addr) ||
>>>> -        netdev_uses_dsa(dev))
>>>> +        !is_valid_ether_addr(dev->dev_addr))
>>>>              return -EINVAL;
>>>>
>>>>      /* No bridging of bridges */
>>>> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
>>>> index d5c34f36f0f4..396bc0c18cb5 100644
>>>> --- a/net/bridge/br_input.c
>>>> +++ b/net/bridge/br_input.c
>>>> @@ -17,6 +17,7 @@
>>>>  #endif
>>>>  #include <linux/neighbour.h>
>>>>  #include <net/arp.h>
>>>> +#include <net/dsa.h>
>>>>  #include <linux/export.h>
>>>>  #include <linux/rculist.h>
>>>>  #include "br_private.h"
>>>> @@ -263,7 +264,8 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
>>>>      struct sk_buff *skb = *pskb;
>>>>      const unsigned char *dest = eth_hdr(skb)->h_dest;
>>>>
>>>> -    if (unlikely(skb->pkt_type == PACKET_LOOPBACK))
>>>> +    if (unlikely(skb->pkt_type == PACKET_LOOPBACK) ||
>>>> +        netdev_uses_dsa(skb->dev))
>>>>              return RX_HANDLER_PASS;
>>>>
>>>>      if (!is_valid_ether_addr(eth_hdr(skb)->h_source))
>>>>
>>>
>>> Yet another test in fast-path for all packets.
>>> Since br_handle_frame will not be executed at all for such devices I'd suggest
>>> to look into a scheme that avoid installing rx_handler and thus prevents br_handle_frame
>>> to be called in the frist place. In case that is not possible then we can discuss adding
>>> one more test in fast-path.
>>>
>>> Actually you can just add a dummy rx_handler that simply returns RX_HANDLER_PASS for
>>> these devices and keep rx_handler_data so all br_port_get_* will continue working.
>>>
>>> Thanks,
>>>  Nik
>>>
> 
> Actually both of those are problematic, since br_port_get_check_rcu
> and br_port_get_check_rtnl check for the rx_handler pointer against
> br_handle_frame.

Right, but they can be changed to use a different validation.

> Actually a plain old revert of 8db0a2ee2c63 works just fine for what I
> need it to, not sure if there's any point in making this any more
> complicated than that.
> What do you think?
> 

Sounds much better to me if it works for you.

Thanks!

> Thanks,
> -Vladimir
> 


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

* Re: [PATCH net-next 1/4] bridge: Allow enslaving DSA master network devices
  2020-04-30 17:50       ` Vladimir Oltean
  2020-04-30 17:54         ` Vladimir Oltean
  2020-04-30 17:55         ` Nikolay Aleksandrov
@ 2020-04-30 17:56         ` Florian Fainelli
  2 siblings, 0 replies; 12+ messages in thread
From: Florian Fainelli @ 2020-04-30 17:56 UTC (permalink / raw)
  To: Vladimir Oltean, Nikolay Aleksandrov
  Cc: Andrew Lunn, Vivien Didelot, David S. Miller, Jiri Pirko,
	Ido Schimmel, Jakub Kicinski, netdev, Li Yang, Roopa Prabhu

On 4/30/20 10:50 AM, Vladimir Oltean wrote:
> Hi Nikolay, Roopa,
> 
> On Wed, 29 Apr 2020 at 19:33, Nikolay Aleksandrov
> <nikolay@cumulusnetworks.com> wrote:
>>
>> +CC Roopa
>>
>> On 29/04/2020 19:27, Nikolay Aleksandrov wrote:
>>> On 29/04/2020 19:19, Vladimir Oltean wrote:
>>>> From: Florian Fainelli <f.fainelli@gmail.com>
>>>>
>>>> Commit 8db0a2ee2c63 ("net: bridge: reject DSA-enabled master netdevices
>>>> as bridge members") added a special check in br_if.c in order to check
>>>> for a DSA master network device with a tagging protocol configured. This
>>>> was done because back then, such devices, once enslaved in a bridge
>>>> would become inoperative and would not pass DSA tagged traffic anymore
>>>> due to br_handle_frame returning RX_HANDLER_CONSUMED.
>>>>
>>>> But right now we have valid use cases which do require bridging of DSA
>>>> masters. One such example is when the DSA master ports are DSA switch
>>>> ports themselves (in a disjoint tree setup). This should be completely
>>>> equivalent, functionally speaking, from having multiple DSA switches
>>>> hanging off of the ports of a switchdev driver. So we should allow the
>>>> enslaving of DSA tagged master network devices.
>>>>
>>>> Make br_handle_frame() return RX_HANDLER_PASS in order to call into the
>>>> DSA specific tagging protocol handlers, and lift the restriction from
>>>> br_add_if.
>>>>
>>>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>>>> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
>>>> ---
>>>>  net/bridge/br_if.c    | 4 +---
>>>>  net/bridge/br_input.c | 4 +++-
>>>>  2 files changed, 4 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
>>>> index ca685c0cdf95..e0fbdb855664 100644
>>>> --- a/net/bridge/br_if.c
>>>> +++ b/net/bridge/br_if.c
>>>> @@ -18,7 +18,6 @@
>>>>  #include <linux/rtnetlink.h>
>>>>  #include <linux/if_ether.h>
>>>>  #include <linux/slab.h>
>>>> -#include <net/dsa.h>
>>>>  #include <net/sock.h>
>>>>  #include <linux/if_vlan.h>
>>>>  #include <net/switchdev.h>
>>>> @@ -571,8 +570,7 @@ int br_add_if(struct net_bridge *br, struct net_device *dev,
>>>>       */
>>>>      if ((dev->flags & IFF_LOOPBACK) ||
>>>>          dev->type != ARPHRD_ETHER || dev->addr_len != ETH_ALEN ||
>>>> -        !is_valid_ether_addr(dev->dev_addr) ||
>>>> -        netdev_uses_dsa(dev))
>>>> +        !is_valid_ether_addr(dev->dev_addr))
>>>>              return -EINVAL;
>>>>
>>>>      /* No bridging of bridges */
>>>> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
>>>> index d5c34f36f0f4..396bc0c18cb5 100644
>>>> --- a/net/bridge/br_input.c
>>>> +++ b/net/bridge/br_input.c
>>>> @@ -17,6 +17,7 @@
>>>>  #endif
>>>>  #include <linux/neighbour.h>
>>>>  #include <net/arp.h>
>>>> +#include <net/dsa.h>
>>>>  #include <linux/export.h>
>>>>  #include <linux/rculist.h>
>>>>  #include "br_private.h"
>>>> @@ -263,7 +264,8 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
>>>>      struct sk_buff *skb = *pskb;
>>>>      const unsigned char *dest = eth_hdr(skb)->h_dest;
>>>>
>>>> -    if (unlikely(skb->pkt_type == PACKET_LOOPBACK))
>>>> +    if (unlikely(skb->pkt_type == PACKET_LOOPBACK) ||
>>>> +        netdev_uses_dsa(skb->dev))
>>>>              return RX_HANDLER_PASS;
>>>>
>>>>      if (!is_valid_ether_addr(eth_hdr(skb)->h_source))
>>>>
>>>
>>> Yet another test in fast-path for all packets.
>>> Since br_handle_frame will not be executed at all for such devices I'd suggest
>>> to look into a scheme that avoid installing rx_handler and thus prevents br_handle_frame
>>> to be called in the frist place. In case that is not possible then we can discuss adding
>>> one more test in fast-path.
>>>
>>> Actually you can just add a dummy rx_handler that simply returns RX_HANDLER_PASS for
>>> these devices and keep rx_handler_data so all br_port_get_* will continue working.
>>>
>>> Thanks,
>>>  Nik
>>>
> 
> Actually both of those are problematic, since br_port_get_check_rcu
> and br_port_get_check_rtnl check for the rx_handler pointer against
> br_handle_frame.
> Actually a plain old revert of 8db0a2ee2c63 works just fine for what I
> need it to, not sure if there's any point in making this any more
> complicated than that.
> What do you think?

We would still be leaving single switch fabric with no nested tagging
non functional if we allow a DSA master to be enslaved into the bridge I
believe, unless something changed in how handlers are processed between
8db0a2ee2c63 and now.

From what you described to me, your Ocelot/Felix interfaces are DSA
slaves from one side, and DSA master for the sja1105 network devices. We
could change the netdev_uses_dsa() into something slightly more
elaborate, which is reflective of whether there is nested tagging being
used.
-- 
Florian

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

* Re: [PATCH net-next 1/4] bridge: Allow enslaving DSA master network devices
  2020-04-30 17:55         ` Nikolay Aleksandrov
@ 2020-04-30 18:05           ` Nikolay Aleksandrov
  0 siblings, 0 replies; 12+ messages in thread
From: Nikolay Aleksandrov @ 2020-04-30 18:05 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: Andrew Lunn, Florian Fainelli, Vivien Didelot, David S. Miller,
	Jiri Pirko, Ido Schimmel, Jakub Kicinski, netdev, Li Yang,
	Roopa Prabhu

On 30/04/2020 20:55, Nikolay Aleksandrov wrote:
> On 30/04/2020 20:50, Vladimir Oltean wrote:
>> Hi Nikolay, Roopa,
>>
>> On Wed, 29 Apr 2020 at 19:33, Nikolay Aleksandrov
>> <nikolay@cumulusnetworks.com> wrote:
>>>
>>> +CC Roopa
>>>
>>> On 29/04/2020 19:27, Nikolay Aleksandrov wrote:
>>>> On 29/04/2020 19:19, Vladimir Oltean wrote:
>>>>> From: Florian Fainelli <f.fainelli@gmail.com>
>>>>>
>>>>> Commit 8db0a2ee2c63 ("net: bridge: reject DSA-enabled master netdevices
>>>>> as bridge members") added a special check in br_if.c in order to check
>>>>> for a DSA master network device with a tagging protocol configured. This
>>>>> was done because back then, such devices, once enslaved in a bridge
>>>>> would become inoperative and would not pass DSA tagged traffic anymore
>>>>> due to br_handle_frame returning RX_HANDLER_CONSUMED.
>>>>>
>>>>> But right now we have valid use cases which do require bridging of DSA
>>>>> masters. One such example is when the DSA master ports are DSA switch
>>>>> ports themselves (in a disjoint tree setup). This should be completely
>>>>> equivalent, functionally speaking, from having multiple DSA switches
>>>>> hanging off of the ports of a switchdev driver. So we should allow the
>>>>> enslaving of DSA tagged master network devices.
>>>>>
>>>>> Make br_handle_frame() return RX_HANDLER_PASS in order to call into the
>>>>> DSA specific tagging protocol handlers, and lift the restriction from
>>>>> br_add_if.
>>>>>
>>>>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>>>>> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
>>>>> ---
>>>>>  net/bridge/br_if.c    | 4 +---
>>>>>  net/bridge/br_input.c | 4 +++-
>>>>>  2 files changed, 4 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
>>>>> index ca685c0cdf95..e0fbdb855664 100644
>>>>> --- a/net/bridge/br_if.c
>>>>> +++ b/net/bridge/br_if.c
>>>>> @@ -18,7 +18,6 @@
>>>>>  #include <linux/rtnetlink.h>
>>>>>  #include <linux/if_ether.h>
>>>>>  #include <linux/slab.h>
>>>>> -#include <net/dsa.h>
>>>>>  #include <net/sock.h>
>>>>>  #include <linux/if_vlan.h>
>>>>>  #include <net/switchdev.h>
>>>>> @@ -571,8 +570,7 @@ int br_add_if(struct net_bridge *br, struct net_device *dev,
>>>>>       */
>>>>>      if ((dev->flags & IFF_LOOPBACK) ||
>>>>>          dev->type != ARPHRD_ETHER || dev->addr_len != ETH_ALEN ||
>>>>> -        !is_valid_ether_addr(dev->dev_addr) ||
>>>>> -        netdev_uses_dsa(dev))
>>>>> +        !is_valid_ether_addr(dev->dev_addr))
>>>>>              return -EINVAL;
>>>>>
>>>>>      /* No bridging of bridges */
>>>>> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
>>>>> index d5c34f36f0f4..396bc0c18cb5 100644
>>>>> --- a/net/bridge/br_input.c
>>>>> +++ b/net/bridge/br_input.c
>>>>> @@ -17,6 +17,7 @@
>>>>>  #endif
>>>>>  #include <linux/neighbour.h>
>>>>>  #include <net/arp.h>
>>>>> +#include <net/dsa.h>
>>>>>  #include <linux/export.h>
>>>>>  #include <linux/rculist.h>
>>>>>  #include "br_private.h"
>>>>> @@ -263,7 +264,8 @@ rx_handler_result_t br_handle_frame(struct sk_buff **pskb)
>>>>>      struct sk_buff *skb = *pskb;
>>>>>      const unsigned char *dest = eth_hdr(skb)->h_dest;
>>>>>
>>>>> -    if (unlikely(skb->pkt_type == PACKET_LOOPBACK))
>>>>> +    if (unlikely(skb->pkt_type == PACKET_LOOPBACK) ||
>>>>> +        netdev_uses_dsa(skb->dev))
>>>>>              return RX_HANDLER_PASS;
>>>>>
>>>>>      if (!is_valid_ether_addr(eth_hdr(skb)->h_source))
>>>>>
>>>>
>>>> Yet another test in fast-path for all packets.
>>>> Since br_handle_frame will not be executed at all for such devices I'd suggest
>>>> to look into a scheme that avoid installing rx_handler and thus prevents br_handle_frame
>>>> to be called in the frist place. In case that is not possible then we can discuss adding
>>>> one more test in fast-path.
>>>>
>>>> Actually you can just add a dummy rx_handler that simply returns RX_HANDLER_PASS for
>>>> these devices and keep rx_handler_data so all br_port_get_* will continue working.
>>>>
>>>> Thanks,
>>>>  Nik
>>>>
>>
>> Actually both of those are problematic, since br_port_get_check_rcu
>> and br_port_get_check_rtnl check for the rx_handler pointer against
>> br_handle_frame.
> 
> Right, but they can be changed to use a different validation.
> 

To be more specific I was referring to the most frequently used br_port_get_rcu/rtnl helpers.
The versions with _check can be changed to use a different validation.

>> Actually a plain old revert of 8db0a2ee2c63 works just fine for what I
>> need it to, not sure if there's any point in making this any more
>> complicated than that.
>> What do you think?
>>
> 
> Sounds much better to me if it works for you.
> 
> Thanks!
> 
>> Thanks,
>> -Vladimir
>>
> 


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

end of thread, other threads:[~2020-04-30 18:05 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-29 16:19 [PATCH net-next 0/4] Cross-chip bridging for disjoint DSA trees Vladimir Oltean
2020-04-29 16:19 ` [PATCH net-next 1/4] bridge: Allow enslaving DSA master network devices Vladimir Oltean
2020-04-29 16:27   ` Nikolay Aleksandrov
2020-04-29 16:33     ` Nikolay Aleksandrov
2020-04-30 17:50       ` Vladimir Oltean
2020-04-30 17:54         ` Vladimir Oltean
2020-04-30 17:55         ` Nikolay Aleksandrov
2020-04-30 18:05           ` Nikolay Aleksandrov
2020-04-30 17:56         ` Florian Fainelli
2020-04-29 16:19 ` [PATCH net-next 2/4] net: dsa: permit cross-chip bridging between all trees in the system Vladimir Oltean
2020-04-29 16:19 ` [PATCH net-next 3/4] net: dsa: introduce a dsa_switch_find function Vladimir Oltean
2020-04-29 16:19 ` [PATCH net-next 4/4] net: dsa: sja1105: implement cross-chip bridging operations Vladimir Oltean

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.