2021-04-03 11:51:05

by Oleksij Rempel

[permalink] [raw]
Subject: [PATCH net-next v1 0/9] ar9331: mainline some parts of switch functionality

Till now the ar9331 switch was supporting only port multiplexing mode.
With this patch set we should be able to bridging, VLAN and STP

Oleksij Rempel (9):
net: dsa: add rcv_post call back
net: dsa: tag_ar9331: detect IGMP and MLD packets
net: dsa: qca: ar9331: reorder MDIO write sequence
net: dsa: qca: ar9331: make proper initial port defaults
net: dsa: qca: ar9331: add forwarding database support
net: dsa: qca: ar9331: add ageing time support
net: dsa: qca: ar9331: add bridge support
net: dsa: qca: ar9331: add STP support
net: dsa: qca: ar9331: add vlan support

drivers/net/dsa/qca/ar9331.c | 927 ++++++++++++++++++++++++++++++++++-
include/net/dsa.h | 2 +
net/dsa/dsa.c | 4 +
net/dsa/port.c | 1 +
net/dsa/tag_ar9331.c | 130 +++++
5 files changed, 1059 insertions(+), 5 deletions(-)

--
2.29.2


2021-04-03 11:51:43

by Oleksij Rempel

[permalink] [raw]
Subject: [PATCH net-next v1 9/9] net: dsa: qca: ar9331: add vlan support

This switch provides simple VLAN resolution database for 16 entries (VLANs).
With this database we can cover typical functionalities as port based
VLANs, untagged and tagged egress. Port based ingress filtering.

The VLAN database is working on top of forwarding database. So,
potentially, we can have multiple VLANs on top of multiple bridges.
Hawing one VLAN on top of multiple bridges will fail on different
levels, most probably DSA framework should warn if some one wont to make
something likes this.

Signed-off-by: Oleksij Rempel <[email protected]>
---
drivers/net/dsa/qca/ar9331.c | 255 +++++++++++++++++++++++++++++++++++
1 file changed, 255 insertions(+)

diff --git a/drivers/net/dsa/qca/ar9331.c b/drivers/net/dsa/qca/ar9331.c
index 83b59e771a5f..40062388d4a7 100644
--- a/drivers/net/dsa/qca/ar9331.c
+++ b/drivers/net/dsa/qca/ar9331.c
@@ -67,6 +67,27 @@
#define AR9331_SW_REG_GLOBAL_CTRL 0x30
#define AR9331_SW_GLOBAL_CTRL_MFS_M GENMASK(13, 0)

+#define AR9331_SW_NUM_VLAN_RECORDS 16
+
+#define AR9331_SW_REG_VLAN_TABLE_FUNCTION0 0x40
+#define AR9331_SW_VT0_PRI_EN BIT(31)
+#define AR9331_SW_VT0_PRI GENMASK(30, 28)
+#define AR9331_SW_VT0_VID GENMASK(27, 16)
+#define AR9331_SW_VT0_PORT_NUM GENMASK(11, 8)
+#define AR9331_SW_VT0_FULL_VIO BIT(4)
+#define AR9331_SW_VT0_BUSY BIT(3)
+#define AR9331_SW_VT0_FUNC GENMASK(2, 0)
+#define AR9331_SW_VT0_FUNC_NOP 0
+#define AR9331_SW_VT0_FUNC_FLUSH_ALL 1
+#define AR9331_SW_VT0_FUNC_LOAD_ENTRY 2
+#define AR9331_SW_VT0_FUNC_PURGE_ENTRY 3
+#define AR9331_SW_VT0_FUNC_DEL_PORT 4
+#define AR9331_SW_VT0_FUNC_GET_NEXT 5
+
+#define AR9331_SW_REG_VLAN_TABLE_FUNCTION1 0x44
+#define AR9331_SW_VT1_VALID BIT(11)
+#define AR9331_SW_VT1_VID_MEM GENMASK(9, 0)
+
/* Size of the address resolution table (ARL) */
#define AR9331_SW_NUM_ARL_RECORDS 1024

@@ -308,6 +329,11 @@ struct ar9331_sw_port {
struct spinlock stats_lock;
};

+struct ar9331_sw_vlan_db {
+ u16 vid;
+ u8 port_mask;
+};
+
struct ar9331_sw_fdb {
u8 port_mask;
u8 aging;
@@ -328,6 +354,7 @@ struct ar9331_sw_priv {
struct ar9331_sw_port port[AR9331_SW_PORTS];
int cpu_port;
u32 isolated_ports;
+ struct ar9331_sw_vlan_db vdb[AR9331_SW_NUM_VLAN_RECORDS];
};

static struct ar9331_sw_priv *ar9331_sw_port_to_priv(struct ar9331_sw_port *port)
@@ -1273,6 +1300,231 @@ static void ar9331_sw_port_stp_state_set(struct dsa_switch *ds, int port,
dev_err_ratelimited(priv->dev, "%s: error: %i\n", __func__, ret);
}

+static int ar9331_port_vlan_filtering(struct dsa_switch *ds, int port,
+ bool vlan_filtering,
+ struct netlink_ext_ack *extack)
+{
+ struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
+ struct regmap *regmap = priv->regmap;
+ u32 mode;
+ int ret;
+
+ if (vlan_filtering)
+ mode = AR9331_SW_8021Q_MODE_SECURE;
+ else
+ mode = AR9331_SW_8021Q_MODE_NONE;
+
+ ret = regmap_update_bits(regmap, AR9331_SW_REG_PORT_VLAN(port),
+ AR9331_SW_PORT_VLAN_8021Q_MODE,
+ FIELD_PREP(AR9331_SW_PORT_VLAN_8021Q_MODE,
+ mode));
+ if (ret)
+ dev_err_ratelimited(priv->dev, "%s: error: %pe\n",
+ __func__, ERR_PTR(ret));
+
+ return ret;
+}
+
+static int ar9331_sw_vt_wait(struct ar9331_sw_priv *priv, u32 *f0)
+{
+ struct regmap *regmap = priv->regmap;
+
+ return regmap_read_poll_timeout(regmap,
+ AR9331_SW_REG_VLAN_TABLE_FUNCTION0,
+ *f0, !(*f0 & AR9331_SW_VT0_BUSY),
+ 100, 2000);
+}
+
+static int ar9331_sw_port_vt_rmw(struct ar9331_sw_priv *priv, u16 vid,
+ u8 port_mask_set, u8 port_mask_clr)
+{
+ struct regmap *regmap = priv->regmap;
+ u32 f0, f1, port_mask = 0, port_mask_new, func;
+ struct ar9331_sw_vlan_db *vdb = NULL;
+ int ret, i;
+
+ if (!vid)
+ return 0;
+
+ ret = ar9331_sw_vt_wait(priv, &f0);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(regmap, AR9331_SW_REG_VLAN_TABLE_FUNCTION0, 0);
+ if (ret)
+ goto error;
+
+ ret = regmap_write(regmap, AR9331_SW_REG_VLAN_TABLE_FUNCTION1, 0);
+ if (ret)
+ goto error;
+
+ for (i = 0; i < ARRAY_SIZE(priv->vdb); i++) {
+ if (priv->vdb[i].vid == vid) {
+ vdb = &priv->vdb[i];
+ break;
+ }
+ }
+
+ ret = regmap_read(regmap, AR9331_SW_REG_VLAN_TABLE_FUNCTION1, &f1);
+ if (ret)
+ return ret;
+
+ if (vdb) {
+ port_mask = vdb->port_mask;
+ }
+
+ port_mask_new = port_mask & ~port_mask_clr;
+ port_mask_new |= port_mask_set;
+
+ if (port_mask_new && port_mask_new == port_mask) {
+ dev_info(priv->dev, "%s: no need to overwrite existing valid entry on %x\n",
+ __func__, port_mask_new);
+ return 0;
+ }
+
+ if (port_mask_new) {
+ func = AR9331_SW_VT0_FUNC_LOAD_ENTRY;
+ } else {
+ func = AR9331_SW_VT0_FUNC_PURGE_ENTRY;
+ port_mask_new = port_mask;
+ }
+
+ if (vdb) {
+ vdb->port_mask = port_mask_new;
+
+ if (!port_mask_new)
+ vdb->vid = 0;
+ } else {
+ for (i = 0; i < ARRAY_SIZE(priv->vdb); i++) {
+ if (!priv->vdb[i].vid) {
+ vdb = &priv->vdb[i];
+ break;
+ }
+ }
+
+ if (!vdb) {
+ dev_err_ratelimited(priv->dev, "Local VDB is full\n");
+ return -ENOMEM;
+ }
+ vdb->vid = vid;
+ vdb->port_mask = port_mask_new;
+ }
+
+ f0 = FIELD_PREP(AR9331_SW_VT0_VID, vid) |
+ FIELD_PREP(AR9331_SW_VT0_FUNC, func) |
+ AR9331_SW_VT0_BUSY;
+ f1 = FIELD_PREP(AR9331_SW_VT1_VID_MEM, port_mask_new) |
+ AR9331_SW_VT1_VALID;
+
+ ret = regmap_write(regmap, AR9331_SW_REG_VLAN_TABLE_FUNCTION1, f1);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(regmap, AR9331_SW_REG_VLAN_TABLE_FUNCTION0, f0);
+ if (ret)
+ return ret;
+
+ ret = ar9331_sw_vt_wait(priv, &f0);
+ if (ret)
+ return ret;
+
+ if (f0 & AR9331_SW_VT0_FULL_VIO) {
+ /* cleanup error status */
+ regmap_write(regmap, AR9331_SW_REG_VLAN_TABLE_FUNCTION0, 0);
+ dev_err_ratelimited(priv->dev, "%s: can't add new entry, VT is full\n", __func__);
+ return -ENOMEM;
+ }
+
+ return 0;
+
+error:
+ dev_err_ratelimited(priv->dev, "%s: error: %pe\n", __func__,
+ ERR_PTR(ret));
+
+ return ret;
+}
+
+static int ar9331_port_vlan_set_pvid(struct ar9331_sw_priv *priv, int port,
+ u16 pvid)
+{
+ struct regmap *regmap = priv->regmap;
+ int ret;
+ u32 mask, val;
+
+ mask = AR9331_SW_PORT_VLAN_8021Q_MODE |
+ AR9331_SW_PORT_VLAN_FORCE_DEFALUT_VID_EN |
+ AR9331_SW_PORT_VLAN_FORCE_PORT_VLAN_EN;
+ val = AR9331_SW_PORT_VLAN_FORCE_DEFALUT_VID_EN |
+ AR9331_SW_PORT_VLAN_FORCE_PORT_VLAN_EN |
+ FIELD_PREP(AR9331_SW_PORT_VLAN_8021Q_MODE,
+ AR9331_SW_8021Q_MODE_FALLBACK);
+
+ ret = regmap_update_bits(regmap, AR9331_SW_REG_PORT_VLAN(port),
+ mask, val);
+ if (ret)
+ return ret;
+
+ return regmap_update_bits(regmap, AR9331_SW_REG_PORT_VLAN(port),
+ AR9331_SW_PORT_VLAN_PORT_VID,
+ FIELD_PREP(AR9331_SW_PORT_VLAN_PORT_VID,
+ pvid));
+}
+
+static int ar9331_port_vlan_add(struct dsa_switch *ds, int port,
+ const struct switchdev_obj_port_vlan *vlan,
+ struct netlink_ext_ack *extack)
+{
+ struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
+ struct regmap *regmap = priv->regmap;
+ int ret, mode;
+
+ ret = ar9331_sw_port_vt_rmw(priv, vlan->vid, BIT(port), 0);
+ if (ret)
+ goto error;
+
+ if (vlan->flags & BRIDGE_VLAN_INFO_PVID)
+ ret = ar9331_port_vlan_set_pvid(priv, port, vlan->vid);
+
+ if (ret)
+ goto error;
+
+ if (vlan->flags & BRIDGE_VLAN_INFO_UNTAGGED)
+ mode = AR9331_SW_PORT_CTRL_EG_VLAN_MODE_STRIP;
+ else
+ mode = AR9331_SW_PORT_CTRL_EG_VLAN_MODE_ADD;
+
+ ret = regmap_update_bits(regmap, AR9331_SW_REG_PORT_CTRL(port),
+ AR9331_SW_PORT_CTRL_EG_VLAN_MODE, mode);
+ if (ret)
+ goto error;
+
+ return 0;
+error:
+ dev_err_ratelimited(priv->dev, "%s: error: %pe\n", __func__,
+ ERR_PTR(ret));
+
+ return ret;
+}
+
+static int ar9331_port_vlan_del(struct dsa_switch *ds, int port,
+ const struct switchdev_obj_port_vlan *vlan)
+{
+ struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
+ int ret;
+
+ ret = ar9331_sw_port_vt_rmw(priv, vlan->vid, 0, BIT(port));
+ if (ret)
+ goto error;
+
+ return 0;
+
+error:
+ dev_err_ratelimited(priv->dev, "%s: error: %pe\n", __func__,
+ ERR_PTR(ret));
+
+ return ret;
+}
+
static const struct dsa_switch_ops ar9331_sw_ops = {
.get_tag_protocol = ar9331_sw_get_tag_protocol,
.setup = ar9331_sw_setup,
@@ -1292,6 +1544,9 @@ static const struct dsa_switch_ops ar9331_sw_ops = {
.port_bridge_join = ar9331_sw_port_bridge_join,
.port_bridge_leave = ar9331_sw_port_bridge_leave,
.port_stp_state_set = ar9331_sw_port_stp_state_set,
+ .port_vlan_filtering = ar9331_port_vlan_filtering,
+ .port_vlan_add = ar9331_port_vlan_add,
+ .port_vlan_del = ar9331_port_vlan_del,
};

static irqreturn_t ar9331_sw_irq(int irq, void *data)
--
2.29.2

2021-04-03 11:52:15

by Oleksij Rempel

[permalink] [raw]
Subject: [PATCH net-next v1 2/9] net: dsa: tag_ar9331: detect IGMP and MLD packets

The ar9331 switch is not forwarding IGMP and MLD packets if IGMP
snooping is enabled. This patch is trying to mimic the HW heuristic to take
same decisions as this switch would do to be able to tell the linux
bridge if some packet was prabably forwarded or not.

Signed-off-by: Oleksij Rempel <[email protected]>
---
net/dsa/tag_ar9331.c | 130 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 130 insertions(+)

diff --git a/net/dsa/tag_ar9331.c b/net/dsa/tag_ar9331.c
index 002cf7f952e2..0ba90e0f91bb 100644
--- a/net/dsa/tag_ar9331.c
+++ b/net/dsa/tag_ar9331.c
@@ -6,6 +6,8 @@

#include <linux/bitfield.h>
#include <linux/etherdevice.h>
+#include <linux/igmp.h>
+#include <net/addrconf.h>

#include "dsa_priv.h"

@@ -24,6 +26,69 @@
#define AR9331_HDR_RESERVED_MASK GENMASK(5, 4)
#define AR9331_HDR_PORT_NUM_MASK GENMASK(3, 0)

+/*
+ * This code replicated MLD detection more or less in the same way as the
+ * switch is doing it
+ */
+static int ipv6_mc_check_ip6hdr(struct sk_buff *skb)
+{
+ const struct ipv6hdr *ip6h;
+ unsigned int offset;
+
+ offset = skb_network_offset(skb) + sizeof(*ip6h);
+
+ if (!pskb_may_pull(skb, offset))
+ return -EINVAL;
+
+ ip6h = ipv6_hdr(skb);
+
+ if (ip6h->version != 6)
+ return -EINVAL;
+
+ skb_set_transport_header(skb, offset);
+
+ return 0;
+}
+
+static int ipv6_mc_check_exthdrs(struct sk_buff *skb)
+{
+ const struct ipv6hdr *ip6h;
+ int offset;
+ u8 nexthdr;
+ __be16 frag_off;
+
+ ip6h = ipv6_hdr(skb);
+
+ if (ip6h->nexthdr != IPPROTO_HOPOPTS)
+ return -ENOMSG;
+
+ nexthdr = ip6h->nexthdr;
+ offset = skb_network_offset(skb) + sizeof(*ip6h);
+ offset = ipv6_skip_exthdr(skb, offset, &nexthdr, &frag_off);
+
+ if (offset < 0)
+ return -EINVAL;
+
+ if (nexthdr != IPPROTO_ICMPV6)
+ return -ENOMSG;
+
+ skb_set_transport_header(skb, offset);
+
+ return 0;
+}
+
+static int my_ipv6_mc_check_mld(struct sk_buff *skb)
+{
+ int ret;
+
+ ret = ipv6_mc_check_ip6hdr(skb);
+ if (ret < 0)
+ return ret;
+
+ return ipv6_mc_check_exthdrs(skb);
+}
+
+
static struct sk_buff *ar9331_tag_xmit(struct sk_buff *skb,
struct net_device *dev)
{
@@ -31,6 +96,13 @@ static struct sk_buff *ar9331_tag_xmit(struct sk_buff *skb,
__le16 *phdr;
u16 hdr;

+ if (dp->stp_state == BR_STATE_BLOCKING) {
+ /* TODO: should we reflect it in the stats? */
+ netdev_warn_once(dev, "%s:%i dropping blocking packet\n",
+ __func__, __LINE__);
+ return NULL;
+ }
+
phdr = skb_push(skb, AR9331_HDR_LEN);

hdr = FIELD_PREP(AR9331_HDR_VERSION_MASK, AR9331_HDR_VERSION);
@@ -80,11 +152,69 @@ static struct sk_buff *ar9331_tag_rcv(struct sk_buff *skb,
return skb;
}

+static void ar9331_tag_rcv_post(struct sk_buff *skb)
+{
+ const struct iphdr *iph;
+ unsigned char *dest;
+ int ret;
+
+ /*
+ * Since the switch do not tell us which packets was offloaded we assume
+ * that all of them did. Except:
+ * - port is not configured for forwarding to any other ports
+ * - igmp/mld snooping is enabled
+ * - unicast or multicast flood is disabled on some of bridged ports
+ * - if we have two port bridge and one is not in forwarding state.
+ * - packet was dropped on the output port..
+ * - any other reasons?
+ */
+ skb->offload_fwd_mark = true;
+
+ dest = eth_hdr(skb)->h_dest;
+ /*
+ * Complete not multicast traffic seems to be forwarded automatically,
+ * as long as multicast and unicast flood are enabled
+ */
+ if (!(is_multicast_ether_addr(dest) && !is_broadcast_ether_addr(dest)))
+ return;
+
+
+ /*
+ * Documentation do not providing any usable information on how the
+ * igmp/mld snooping is implemented on this switch. Following
+ * implementation is based on testing, by sending correct and malformed
+ * packets to the switch.
+ * It is not trying to find sane and properly formated packets. Instead
+ * it is trying to be as close to the switch behavior as possible.
+ */
+ skb_reset_network_header(skb);
+ switch (ntohs(skb->protocol)) {
+ case ETH_P_IP:
+
+ if (!pskb_network_may_pull(skb, sizeof(*iph)))
+ break;
+
+ iph = ip_hdr(skb);
+ if (iph->protocol == IPPROTO_IGMP)
+ skb->offload_fwd_mark = false;
+
+ break;
+ case ETH_P_IPV6:
+ ret = my_ipv6_mc_check_mld(skb);
+ if (!ret)
+ skb->offload_fwd_mark = false;
+
+ break;
+ }
+}
+
+
static const struct dsa_device_ops ar9331_netdev_ops = {
.name = "ar9331",
.proto = DSA_TAG_PROTO_AR9331,
.xmit = ar9331_tag_xmit,
.rcv = ar9331_tag_rcv,
+ .rcv_post = ar9331_tag_rcv_post,
.overhead = AR9331_HDR_LEN,
};

--
2.29.2

2021-04-03 11:52:44

by Oleksij Rempel

[permalink] [raw]
Subject: [PATCH net-next v1 8/9] net: dsa: qca: ar9331: add STP support

According to the datasheet, this switch has configurable STP port
states. Suddenly LISTENING and BLOCKING states didn't forwarded packets
to the CPU and linux bridge continuously re enabled ports even if a loop
was detected. To make it work, I reused bridge functionality to isolate
port in LISTENING and BLOCKING states.

Signed-off-by: Oleksij Rempel <[email protected]>
---
drivers/net/dsa/qca/ar9331.c | 69 ++++++++++++++++++++++++++++++++++++
1 file changed, 69 insertions(+)

diff --git a/drivers/net/dsa/qca/ar9331.c b/drivers/net/dsa/qca/ar9331.c
index bf9588574205..83b59e771a5f 100644
--- a/drivers/net/dsa/qca/ar9331.c
+++ b/drivers/net/dsa/qca/ar9331.c
@@ -327,6 +327,7 @@ struct ar9331_sw_priv {
struct reset_control *sw_reset;
struct ar9331_sw_port port[AR9331_SW_PORTS];
int cpu_port;
+ u32 isolated_ports;
};

static struct ar9331_sw_priv *ar9331_sw_port_to_priv(struct ar9331_sw_port *port)
@@ -1151,6 +1152,10 @@ static int ar9331_sw_port_bridge_join(struct dsa_switch *ds, int port,
if (!dsa_is_user_port(ds, port))
continue;

+ /* part of the bridge but should be isolated for now */
+ if (priv->isolated_ports & BIT(i))
+ continue;
+
val = FIELD_PREP(AR9331_SW_PORT_VLAN_PORT_VID_MEMBER, BIT(port));
ret = regmap_set_bits(regmap, AR9331_SW_REG_PORT_VLAN(i), val);
if (ret)
@@ -1205,6 +1210,69 @@ static void ar9331_sw_port_bridge_leave(struct dsa_switch *ds, int port,
dev_err_ratelimited(priv->dev, "%s: error: %i\n", __func__, ret);
}

+static void ar9331_sw_port_stp_state_set(struct dsa_switch *ds, int port,
+ u8 state)
+{
+ struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
+ struct net_device *br = dsa_to_port(ds, port)->bridge_dev;
+ struct regmap *regmap = priv->regmap;
+ u32 port_ctrl = 0, port_state = 0;
+ bool join = false;
+ int ret;
+
+ /*
+ * STP hw support is buggy or I didn't understood it. So, it seems to
+ * be easier to make hand crafted implementation by using bridge
+ * functionality. Similar implementation can be found on ksz9477 switch
+ * and may be we need some generic code to so for all related devices
+ */
+ switch (state) {
+ case BR_STATE_FORWARDING:
+ join = true;
+ fallthrough;
+ case BR_STATE_LEARNING:
+ port_ctrl = AR9331_SW_PORT_CTRL_LEARN_EN;
+ fallthrough;
+ case BR_STATE_LISTENING:
+ case BR_STATE_BLOCKING:
+ port_state = AR9331_SW_PORT_CTRL_PORT_STATE_FORWARD;
+ break;
+ case BR_STATE_DISABLED:
+ default:
+ port_state = AR9331_SW_PORT_CTRL_PORT_STATE_DISABLED;
+ break;
+ }
+
+ port_ctrl |= FIELD_PREP(AR9331_SW_PORT_CTRL_PORT_STATE, port_state);
+
+ ret = regmap_update_bits(regmap, AR9331_SW_REG_PORT_CTRL(port),
+ AR9331_SW_PORT_CTRL_LEARN_EN |
+ AR9331_SW_PORT_CTRL_PORT_STATE, port_ctrl);
+ if (ret)
+ goto error;
+
+ if (!dsa_is_user_port(ds, port))
+ return;
+
+ /*
+ * here we care only about user ports. CPU port do not need this
+ * configuration
+ */
+ if (join) {
+ priv->isolated_ports &= ~BIT(port);
+ if (br)
+ ar9331_sw_port_bridge_join(ds, port, br);
+ } else {
+ priv->isolated_ports |= BIT(port);
+ if (br)
+ ar9331_sw_port_bridge_leave(ds, port, br);
+ }
+
+ return;
+error:
+ dev_err_ratelimited(priv->dev, "%s: error: %i\n", __func__, ret);
+}
+
static const struct dsa_switch_ops ar9331_sw_ops = {
.get_tag_protocol = ar9331_sw_get_tag_protocol,
.setup = ar9331_sw_setup,
@@ -1223,6 +1291,7 @@ static const struct dsa_switch_ops ar9331_sw_ops = {
.set_ageing_time = ar9331_sw_set_ageing_time,
.port_bridge_join = ar9331_sw_port_bridge_join,
.port_bridge_leave = ar9331_sw_port_bridge_leave,
+ .port_stp_state_set = ar9331_sw_port_stp_state_set,
};

static irqreturn_t ar9331_sw_irq(int irq, void *data)
--
2.29.2

2021-04-03 11:52:45

by Oleksij Rempel

[permalink] [raw]
Subject: [PATCH net-next v1 3/9] net: dsa: qca: ar9331: reorder MDIO write sequence

In case of this switch we work with 32bit registers on top of 16bit
bus. Some registers (for example access to forwarding database) have
trigger bit on the first 16bit half of request and the result +
configuration of request in the second half. Without this this patch, we would
trigger database operation and overwrite result in one run.

To make it work properly, we should do the second part of transfer
before the first one is done.

So far, this rule seems to work for all registers on this switch.

Signed-off-by: Oleksij Rempel <[email protected]>
---
drivers/net/dsa/qca/ar9331.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/dsa/qca/ar9331.c b/drivers/net/dsa/qca/ar9331.c
index ca2ad77b71f1..9a5035b2f0ff 100644
--- a/drivers/net/dsa/qca/ar9331.c
+++ b/drivers/net/dsa/qca/ar9331.c
@@ -837,16 +837,17 @@ static int ar9331_mdio_write(void *ctx, u32 reg, u32 val)
return 0;
}

- ret = __ar9331_mdio_write(sbus, AR9331_SW_MDIO_PHY_MODE_REG, reg, val);
+ ret = __ar9331_mdio_write(sbus, AR9331_SW_MDIO_PHY_MODE_REG, reg + 2,
+ val >> 16);
if (ret < 0)
goto error;

- ret = __ar9331_mdio_write(sbus, AR9331_SW_MDIO_PHY_MODE_REG, reg + 2,
- val >> 16);
+ ret = __ar9331_mdio_write(sbus, AR9331_SW_MDIO_PHY_MODE_REG, reg, val);
if (ret < 0)
goto error;

return 0;
+
error:
dev_err_ratelimited(&sbus->dev, "Bus error. Failed to write register.\n");
return ret;
--
2.29.2

2021-04-03 11:54:05

by Oleksij Rempel

[permalink] [raw]
Subject: [PATCH net-next v1 7/9] net: dsa: qca: ar9331: add bridge support

This switch is providing forwarding matrix, with it we can configure
individual bridges. Potentially we can configure more then one not VLAN
based bridge on this HW.

Signed-off-by: Oleksij Rempel <[email protected]>
---
drivers/net/dsa/qca/ar9331.c | 73 ++++++++++++++++++++++++++++++++++++
1 file changed, 73 insertions(+)

diff --git a/drivers/net/dsa/qca/ar9331.c b/drivers/net/dsa/qca/ar9331.c
index b2c22ba924f0..bf9588574205 100644
--- a/drivers/net/dsa/qca/ar9331.c
+++ b/drivers/net/dsa/qca/ar9331.c
@@ -40,6 +40,7 @@
*/

#include <linux/bitfield.h>
+#include <linux/if_bridge.h>
#include <linux/module.h>
#include <linux/of_irq.h>
#include <linux/of_mdio.h>
@@ -1134,6 +1135,76 @@ static int ar9331_sw_set_ageing_time(struct dsa_switch *ds,
val);
}

+static int ar9331_sw_port_bridge_join(struct dsa_switch *ds, int port,
+ struct net_device *br)
+{
+ struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
+ struct regmap *regmap = priv->regmap;
+ int port_mask = BIT(priv->cpu_port);
+ int i, ret;
+ u32 val;
+
+ for (i = 0; i < ds->num_ports; i++) {
+ if (dsa_to_port(ds, i)->bridge_dev != br)
+ continue;
+
+ if (!dsa_is_user_port(ds, port))
+ continue;
+
+ val = FIELD_PREP(AR9331_SW_PORT_VLAN_PORT_VID_MEMBER, BIT(port));
+ ret = regmap_set_bits(regmap, AR9331_SW_REG_PORT_VLAN(i), val);
+ if (ret)
+ goto error;
+
+ if (i != port)
+ port_mask |= BIT(i);
+ }
+
+ val = FIELD_PREP(AR9331_SW_PORT_VLAN_PORT_VID_MEMBER, port_mask);
+ ret = regmap_update_bits(regmap, AR9331_SW_REG_PORT_VLAN(port),
+ AR9331_SW_PORT_VLAN_PORT_VID_MEMBER, val);
+ if (ret)
+ goto error;
+
+ return 0;
+error:
+ dev_err_ratelimited(priv->dev, "%s: error: %i\n", __func__, ret);
+
+ return ret;
+}
+
+static void ar9331_sw_port_bridge_leave(struct dsa_switch *ds, int port,
+ struct net_device *br)
+{
+ struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
+ struct regmap *regmap = priv->regmap;
+ int i, ret;
+ u32 val;
+
+ for (i = 0; i < ds->num_ports; i++) {
+ if (dsa_to_port(ds, i)->bridge_dev != br)
+ continue;
+
+ if (!dsa_is_user_port(ds, port))
+ continue;
+
+ val = FIELD_PREP(AR9331_SW_PORT_VLAN_PORT_VID_MEMBER, BIT(port));
+ ret = regmap_clear_bits(regmap, AR9331_SW_REG_PORT_VLAN(i), val);
+ if (ret)
+ goto error;
+ }
+
+ val = FIELD_PREP(AR9331_SW_PORT_VLAN_PORT_VID_MEMBER, BIT(priv->cpu_port));
+ ret = regmap_update_bits(regmap, AR9331_SW_REG_PORT_VLAN(port),
+ AR9331_SW_PORT_VLAN_PORT_VID_MEMBER, val);
+ if (ret)
+ goto error;
+
+ return;
+error:
+ dev_err_ratelimited(priv->dev, "%s: error: %i\n", __func__, ret);
+}
+
static const struct dsa_switch_ops ar9331_sw_ops = {
.get_tag_protocol = ar9331_sw_get_tag_protocol,
.setup = ar9331_sw_setup,
@@ -1150,6 +1221,8 @@ static const struct dsa_switch_ops ar9331_sw_ops = {
.port_mdb_add = ar9331_sw_port_mdb_add,
.port_mdb_del = ar9331_sw_port_mdb_del,
.set_ageing_time = ar9331_sw_set_ageing_time,
+ .port_bridge_join = ar9331_sw_port_bridge_join,
+ .port_bridge_leave = ar9331_sw_port_bridge_leave,
};

static irqreturn_t ar9331_sw_irq(int irq, void *data)
--
2.29.2

2021-04-03 11:54:45

by Oleksij Rempel

[permalink] [raw]
Subject: [PATCH net-next v1 5/9] net: dsa: qca: ar9331: add forwarding database support

This switch provides simple address resolution table, without VLAN or
multicast specific information.
With this patch we are able now to read, modify unicast and mulicast
addresses.

Signed-off-by: Oleksij Rempel <[email protected]>
---
drivers/net/dsa/qca/ar9331.c | 356 +++++++++++++++++++++++++++++++++++
1 file changed, 356 insertions(+)

diff --git a/drivers/net/dsa/qca/ar9331.c b/drivers/net/dsa/qca/ar9331.c
index a3de3598fbf5..4a98f14f31f4 100644
--- a/drivers/net/dsa/qca/ar9331.c
+++ b/drivers/net/dsa/qca/ar9331.c
@@ -66,6 +66,47 @@
#define AR9331_SW_REG_GLOBAL_CTRL 0x30
#define AR9331_SW_GLOBAL_CTRL_MFS_M GENMASK(13, 0)

+/* Size of the address resolution table (ARL) */
+#define AR9331_SW_NUM_ARL_RECORDS 1024
+
+#define AR9331_SW_REG_ADDR_TABLE_FUNCTION0 0x50
+#define AR9331_SW_AT_ADDR_BYTES4 GENMASK(31, 24)
+#define AR9331_SW_AT_ADDR_BYTES5 GENMASK(23, 16)
+#define AR9331_SW_AT_FULL_VIO BIT(12)
+#define AR9331_SW_AT_PORT_NUM GENMASK(11, 8)
+#define AR9331_SW_AT_FLUSH_STATIC_EN BIT(4)
+#define AR9331_SW_AT_BUSY BIT(3)
+#define AR9331_SW_AT_FUNC GENMASK(2, 0)
+#define AR9331_SW_AT_FUNC_NOP 0
+#define AR9331_SW_AT_FUNC_FLUSH_ALL 1
+#define AR9331_SW_AT_FUNC_LOAD_ENTRY 2
+#define AR9331_SW_AT_FUNC_PURGE_ENTRY 3
+#define AR9331_SW_AT_FUNC_FLUSH_ALL_UNLOCKED 4
+#define AR9331_SW_AT_FUNC_FLUSH_PORT 5
+#define AR9331_SW_AT_FUNC_GET_NEXT 6
+#define AR9331_SW_AT_FUNC_FIND_MAC 7
+
+#define AR9331_SW_REG_ADDR_TABLE_FUNCTION1 0x54
+#define AR9331_SW_AT_ADDR_BYTES0 GENMASK(31, 24)
+#define AR9331_SW_AT_ADDR_BYTES1 GENMASK(23, 16)
+#define AR9331_SW_AT_ADDR_BYTES2 GENMASK(15, 8)
+#define AR9331_SW_AT_ADDR_BYTES3 GENMASK(7, 0)
+
+#define AR9331_SW_REG_ADDR_TABLE_FUNCTION2 0x58
+#define AR9331_SW_AT_COPY_TO_CPU BIT(26)
+#define AR9331_SW_AT_REDIRECT_TOCPU BIT(25)
+#define AR9331_SW_AT_LEAKY_EN BIT(24)
+#define AR9331_SW_AT_STATUS GENMASK(19, 16)
+#define AR9331_SW_AT_STATUS_EMPTY 0
+/* STATUS values from 7 to 1 are different aging levels */
+#define AR9331_SW_AT_STATUS_STATIC 0xf
+
+#define AR9331_SW_AT_SA_DROP_EN BIT(14)
+#define AR9331_SW_AT_MIRROR_EN BIT(13)
+#define AR9331_SW_AT_PRIORITY_EN BIT(12)
+#define AR9331_SW_AT_PRIORITY GENMASK(11, 10)
+#define AR9331_SW_AT_DES_PORT GENMASK(5, 0)
+
#define AR9331_SW_REG_ADDR_TABLE_CTRL 0x5c
#define AR9331_SW_AT_ARP_EN BIT(20)
#define AR9331_SW_AT_LEARN_CHANGE_EN BIT(18)
@@ -266,6 +307,12 @@ struct ar9331_sw_port {
struct spinlock stats_lock;
};

+struct ar9331_sw_fdb {
+ u8 port_mask;
+ u8 aging;
+ u8 mac[ETH_ALEN];
+};
+
struct ar9331_sw_priv {
struct device *dev;
struct dsa_switch ds;
@@ -765,6 +812,309 @@ static void ar9331_get_stats64(struct dsa_switch *ds, int port,
spin_unlock(&p->stats_lock);
}

+static int ar9331_sw_fdb_wait(struct ar9331_sw_priv *priv, u32 *f0)
+{
+ struct regmap *regmap = priv->regmap;
+
+ return regmap_read_poll_timeout(regmap,
+ AR9331_SW_REG_ADDR_TABLE_FUNCTION0,
+ *f0, !(*f0 & AR9331_SW_AT_BUSY),
+ 10, 2000);
+}
+
+static int ar9331_sw_port_fdb_write(struct ar9331_sw_priv *priv,
+ u32 f0, u32 f1, u32 f2)
+{
+ struct regmap *regmap = priv->regmap;
+ int ret;
+
+ ret = regmap_write(regmap, AR9331_SW_REG_ADDR_TABLE_FUNCTION2, f2);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(regmap, AR9331_SW_REG_ADDR_TABLE_FUNCTION1, f1);
+ if (ret)
+ return ret;
+
+ return regmap_write(regmap, AR9331_SW_REG_ADDR_TABLE_FUNCTION0, f0);
+}
+
+static int ar9331_sw_fdb_next(struct ar9331_sw_priv *priv,
+ struct ar9331_sw_fdb *fdb, int port)
+{
+ struct regmap *regmap = priv->regmap;
+ unsigned int status, ports;
+ u32 f0, f1, f2;
+ int ret;
+
+ /* Keep AT_ADDR_BYTES4/5 to search next entry after current */
+ ret = regmap_update_bits(regmap, AR9331_SW_REG_ADDR_TABLE_FUNCTION0,
+ AR9331_SW_AT_FUNC | AR9331_SW_AT_BUSY,
+ AR9331_SW_AT_BUSY |
+ FIELD_PREP(AR9331_SW_AT_FUNC,
+ AR9331_SW_AT_FUNC_GET_NEXT));
+ if (ret)
+ return ret;
+
+ ret = ar9331_sw_fdb_wait(priv, &f0);
+ if (ret)
+ return ret;
+
+ ret = regmap_read(regmap, AR9331_SW_REG_ADDR_TABLE_FUNCTION2, &f2);
+ if (ret)
+ return ret;
+
+ /*
+ * If the hardware returns an MAC != 0 and the AT_STATUS is zero, there
+ * is no next valid entry in the address table.
+ */
+ status = FIELD_GET(AR9331_SW_AT_STATUS, f2);
+ fdb->aging = status;
+ if (!status)
+ return 0;
+
+ ret = regmap_read(regmap, AR9331_SW_REG_ADDR_TABLE_FUNCTION1, &f1);
+ if (ret)
+ return ret;
+
+ fdb->mac[0] = FIELD_GET(AR9331_SW_AT_ADDR_BYTES0, f1);
+ fdb->mac[1] = FIELD_GET(AR9331_SW_AT_ADDR_BYTES1, f1);
+ fdb->mac[2] = FIELD_GET(AR9331_SW_AT_ADDR_BYTES2, f1);
+ fdb->mac[3] = FIELD_GET(AR9331_SW_AT_ADDR_BYTES3, f1);
+ fdb->mac[4] = FIELD_GET(AR9331_SW_AT_ADDR_BYTES4, f0);
+ fdb->mac[5] = FIELD_GET(AR9331_SW_AT_ADDR_BYTES5, f0);
+
+ ports = FIELD_GET(AR9331_SW_AT_DES_PORT, f2);
+ if (!(ports & BIT(port)))
+ return -EAGAIN;
+
+ return 0;
+}
+
+static void ar9331_sw_port_fdb_prepare(const unsigned char *mac, u32 *f0,
+ u32 *f1, unsigned int func)
+{
+ *f1 = FIELD_PREP(AR9331_SW_AT_ADDR_BYTES0, mac[0]) |
+ FIELD_PREP(AR9331_SW_AT_ADDR_BYTES1, mac[1]) |
+ FIELD_PREP(AR9331_SW_AT_ADDR_BYTES2, mac[2]) |
+ FIELD_PREP(AR9331_SW_AT_ADDR_BYTES3, mac[3]);
+ *f0 = FIELD_PREP(AR9331_SW_AT_ADDR_BYTES4, mac[4]) |
+ FIELD_PREP(AR9331_SW_AT_ADDR_BYTES5, mac[5]) |
+ FIELD_PREP(AR9331_SW_AT_FUNC, func) | AR9331_SW_AT_BUSY;
+}
+
+static int ar9331_sw_port_fdb_dump(struct dsa_switch *ds, int port,
+ dsa_fdb_dump_cb_t *cb, void *data)
+{
+ struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
+ int cnt = AR9331_SW_NUM_ARL_RECORDS;
+ struct ar9331_sw_fdb _fdb = { 0 };
+ bool is_static;
+ int ret;
+ u32 f0;
+
+ /*
+ * Make sure no pending operation is in progress. Since no timeout and
+ * interval values are documented, we use here "seems to be sane, works
+ * for me" values.
+ */
+ ret = ar9331_sw_fdb_wait(priv, &f0);
+ if (ret)
+ return ret;
+
+ /*
+ * If the address and the AT_STATUS are both zero, the hardware will
+ * search the first valid entry from entry0.
+ * If the address is set to zero and the AT_STATUS is not zero, the
+ * hardware will discover the next valid entry which has an address
+ * of 0x0.
+ */
+ ret = ar9331_sw_port_fdb_write(priv, 0, 0, 0);
+ if (ret)
+ return ret;
+
+ while (cnt--) {
+ ret = ar9331_sw_fdb_next(priv, &_fdb, port);
+ if (ret == -EAGAIN)
+ continue;
+ else if (ret)
+ return ret;
+
+ if (!_fdb.aging)
+ break;
+
+ is_static = (_fdb.aging == AR9331_SW_AT_STATUS_STATIC);
+ ret = cb(_fdb.mac, 0, is_static, data);
+ if (ret)
+ break;
+ }
+
+ return ret;
+}
+
+static int ar9331_sw_port_fdb_rmw(struct ar9331_sw_priv *priv,
+ const unsigned char *mac,
+ u8 port_mask_set,
+ u8 port_mask_clr)
+{
+ struct regmap *regmap = priv->regmap;
+ u32 f0, f1, f2;
+ u8 port_mask, port_mask_new, status, func;
+ int ret;
+
+ ret = ar9331_sw_fdb_wait(priv, &f0);
+ if (ret)
+ return ret;
+
+ ar9331_sw_port_fdb_prepare(mac, &f0, &f1, AR9331_SW_AT_FUNC_FIND_MAC);
+
+ ret = ar9331_sw_port_fdb_write(priv, f0, f1, f2);
+ if (ret)
+ return ret;
+
+ ret = ar9331_sw_fdb_wait(priv, &f0);
+ if (ret)
+ return ret;
+
+ ret = regmap_read(regmap, AR9331_SW_REG_ADDR_TABLE_FUNCTION2, &f2);
+ if (ret)
+ return ret;
+
+ port_mask = FIELD_GET(AR9331_SW_AT_DES_PORT, f2);
+ status = FIELD_GET(AR9331_SW_AT_STATUS, f2);
+ if (status > 0 && status < AR9331_SW_AT_STATUS_STATIC) {
+ dev_err_ratelimited(priv->dev, "%s: found existing dynamic entry on %x\n",
+ __func__, port_mask);
+
+ if (port_mask_set && port_mask_set != port_mask)
+ dev_err_ratelimited(priv->dev, "%s: found existing dynamic entry on %x, replacing it with static on %x\n",
+ __func__, port_mask, port_mask_set);
+ port_mask = 0;
+ } else if (!status && !port_mask_set) {
+ return 0;
+ }
+
+ port_mask_new = port_mask & ~port_mask_clr;
+ port_mask_new |= port_mask_set;
+
+ if (port_mask_new == port_mask &&
+ status == AR9331_SW_AT_STATUS_STATIC) {
+ dev_info(priv->dev, "%s: no need to overwrite existing valid entry on %x\n",
+ __func__, port_mask_new);
+ return 0;
+ }
+
+ if (port_mask_new) {
+ func = AR9331_SW_AT_FUNC_LOAD_ENTRY;
+ } else {
+ func = AR9331_SW_AT_FUNC_PURGE_ENTRY;
+ port_mask_new = port_mask;
+ }
+
+ f2 = FIELD_PREP(AR9331_SW_AT_DES_PORT, port_mask_new) |
+ FIELD_PREP(AR9331_SW_AT_STATUS, AR9331_SW_AT_STATUS_STATIC);
+
+ ar9331_sw_port_fdb_prepare(mac, &f0, &f1, func);
+
+ ret = ar9331_sw_port_fdb_write(priv, f0, f1, f2);
+ if (ret)
+ return ret;
+
+ ret = ar9331_sw_fdb_wait(priv, &f0);
+ if (ret)
+ return ret;
+
+ if (f0 & AR9331_SW_AT_FULL_VIO) {
+ /* cleanup error status */
+ regmap_write(regmap, AR9331_SW_REG_ADDR_TABLE_FUNCTION0, 0);
+ dev_err_ratelimited(priv->dev, "%s: can't add new entry, ATU is full\n", __func__);
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+
+
+static int ar9331_sw_port_fdb_add(struct dsa_switch *ds, int port,
+ const unsigned char *mac, u16 vid)
+{
+ struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
+ u16 port_mask = BIT(port);
+
+ dev_info(priv->dev, "%s(%pM, %x)\n", __func__, mac, port);
+
+ if (vid)
+ return -EINVAL;
+
+ return ar9331_sw_port_fdb_rmw(priv, mac, port_mask, 0);
+}
+
+static int ar9331_sw_port_fdb_del(struct dsa_switch *ds, int port,
+ const unsigned char *mac, u16 vid)
+{
+ struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
+ u16 port_mask = BIT(port);
+
+ if (vid)
+ return -EINVAL;
+
+ return ar9331_sw_port_fdb_rmw(priv, mac, 0, port_mask);
+}
+
+static int ar9331_sw_port_mdb_add(struct dsa_switch *ds, int port,
+ const struct switchdev_obj_port_mdb *mdb)
+{
+ struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
+ u16 port_mask = BIT(port);
+
+ if (mdb->vid)
+ return -EOPNOTSUPP;
+
+ return ar9331_sw_port_fdb_rmw(priv, mdb->addr, port_mask, 0);
+}
+
+static int ar9331_sw_port_mdb_del(struct dsa_switch *ds, int port,
+ const struct switchdev_obj_port_mdb *mdb)
+{
+ struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
+ u16 port_mask = BIT(port);
+
+ if (mdb->vid)
+ return -EOPNOTSUPP;
+
+ return ar9331_sw_port_fdb_rmw(priv, mdb->addr, 0, port_mask);
+}
+
+static void ar9331_sw_port_fast_age(struct dsa_switch *ds, int port)
+{
+ struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
+ struct regmap *regmap = priv->regmap;
+ int ret;
+ u32 f0;
+
+ ret = ar9331_sw_fdb_wait(priv, &f0);
+ if (ret)
+ goto error;
+
+ /* Flush all non static unicast address on a given port */
+ f0 = FIELD_PREP(AR9331_SW_AT_PORT_NUM, port) |
+ FIELD_PREP(AR9331_SW_AT_FUNC, AR9331_SW_AT_FUNC_FLUSH_PORT) |
+ AR9331_SW_AT_BUSY;
+
+ ret = regmap_write(regmap, AR9331_SW_REG_ADDR_TABLE_FUNCTION0, f0);
+ if (ret)
+ goto error;
+
+ ret = ar9331_sw_fdb_wait(priv, &f0);
+ if (ret)
+ goto error;
+
+ return;
+error:
+ dev_err_ratelimited(priv->dev, "%s: error: %i\n", __func__, ret);
+}
+
static const struct dsa_switch_ops ar9331_sw_ops = {
.get_tag_protocol = ar9331_sw_get_tag_protocol,
.setup = ar9331_sw_setup,
@@ -774,6 +1124,12 @@ static const struct dsa_switch_ops ar9331_sw_ops = {
.phylink_mac_link_down = ar9331_sw_phylink_mac_link_down,
.phylink_mac_link_up = ar9331_sw_phylink_mac_link_up,
.get_stats64 = ar9331_get_stats64,
+ .port_fast_age = ar9331_sw_port_fast_age,
+ .port_fdb_del = ar9331_sw_port_fdb_del,
+ .port_fdb_add = ar9331_sw_port_fdb_add,
+ .port_fdb_dump = ar9331_sw_port_fdb_dump,
+ .port_mdb_add = ar9331_sw_port_mdb_add,
+ .port_mdb_del = ar9331_sw_port_mdb_del,
};

static irqreturn_t ar9331_sw_irq(int irq, void *data)
--
2.29.2

2021-04-03 13:05:50

by Vladimir Oltean

[permalink] [raw]
Subject: Re: [PATCH net-next v1 2/9] net: dsa: tag_ar9331: detect IGMP and MLD packets

Hi Oleksij,

On Sat, Apr 03, 2021 at 01:48:41PM +0200, Oleksij Rempel wrote:
> The ar9331 switch is not forwarding IGMP and MLD packets if IGMP
> snooping is enabled. This patch is trying to mimic the HW heuristic to take
> same decisions as this switch would do to be able to tell the linux
> bridge if some packet was prabably forwarded or not.
>
> Signed-off-by: Oleksij Rempel <[email protected]>
> ---

I am not familiar with IGMP/MLD, therefore I don't really understand
what problem you are trying to solve.

Your switch has packet traps for IGMP and MLD, ok. So it doesn't forward
them. Must the IGMP/MLD packets be forwarded by an IGMP/MLD snooping
bridge? Which ones and under what circumstances?

2021-04-03 13:37:16

by Oleksij Rempel

[permalink] [raw]
Subject: Re: [PATCH net-next v1 2/9] net: dsa: tag_ar9331: detect IGMP and MLD packets

On Sat, Apr 03, 2021 at 04:03:18PM +0300, Vladimir Oltean wrote:
> Hi Oleksij,
>
> On Sat, Apr 03, 2021 at 01:48:41PM +0200, Oleksij Rempel wrote:
> > The ar9331 switch is not forwarding IGMP and MLD packets if IGMP
> > snooping is enabled. This patch is trying to mimic the HW heuristic to take
> > same decisions as this switch would do to be able to tell the linux
> > bridge if some packet was prabably forwarded or not.
> >
> > Signed-off-by: Oleksij Rempel <[email protected]>
> > ---
>
> I am not familiar with IGMP/MLD, therefore I don't really understand
> what problem you are trying to solve.
>
> Your switch has packet traps for IGMP and MLD, ok. So it doesn't forward
> them. Must the IGMP/MLD packets be forwarded by an IGMP/MLD snooping
> bridge? Which ones and under what circumstances?

I'll better refer to the rfc:
https://tools.ietf.org/html/rfc4541

Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

2021-04-03 13:48:13

by Vladimir Oltean

[permalink] [raw]
Subject: Re: [PATCH net-next v1 2/9] net: dsa: tag_ar9331: detect IGMP and MLD packets

On Sat, Apr 03, 2021 at 03:26:36PM +0200, Oleksij Rempel wrote:
> On Sat, Apr 03, 2021 at 04:03:18PM +0300, Vladimir Oltean wrote:
> > Hi Oleksij,
> >
> > On Sat, Apr 03, 2021 at 01:48:41PM +0200, Oleksij Rempel wrote:
> > > The ar9331 switch is not forwarding IGMP and MLD packets if IGMP
> > > snooping is enabled. This patch is trying to mimic the HW heuristic to take
> > > same decisions as this switch would do to be able to tell the linux
> > > bridge if some packet was prabably forwarded or not.
> > >
> > > Signed-off-by: Oleksij Rempel <[email protected]>
> > > ---
> >
> > I am not familiar with IGMP/MLD, therefore I don't really understand
> > what problem you are trying to solve.
> >
> > Your switch has packet traps for IGMP and MLD, ok. So it doesn't forward
> > them. Must the IGMP/MLD packets be forwarded by an IGMP/MLD snooping
> > bridge? Which ones and under what circumstances?
>
> I'll better refer to the rfc:
> https://tools.ietf.org/html/rfc4541

Ok, the question might have been a little bit dumb.
I found this PDF:
https://www.alliedtelesis.com/sites/default/files/documents/how-alliedware/howto_config_igmp1.pdf
and it explains that:
- a snooper floods the Membership Query messages from the network's
querier towards all ports that are not blocked by STP
- a snooper forwards all Membership Report messages from a client
towards the All Groups port (which is how it reaches the querier).

I'm asking this because I just want to understand what the bridge code
does. Does the code path for IGMP_HOST_MEMBERSHIP_REPORT (for example)
for a snooper go through should_deliver -> nbp_switchdev_allowed_egress,
which is what you are affecting here?

2021-04-03 14:51:00

by Andrew Lunn

[permalink] [raw]
Subject: Re: [PATCH net-next v1 2/9] net: dsa: tag_ar9331: detect IGMP and MLD packets

> @@ -31,6 +96,13 @@ static struct sk_buff *ar9331_tag_xmit(struct sk_buff *skb,
> __le16 *phdr;
> u16 hdr;
>
> + if (dp->stp_state == BR_STATE_BLOCKING) {
> + /* TODO: should we reflect it in the stats? */
> + netdev_warn_once(dev, "%s:%i dropping blocking packet\n",
> + __func__, __LINE__);
> + return NULL;
> + }
> +
> phdr = skb_push(skb, AR9331_HDR_LEN);
>
> hdr = FIELD_PREP(AR9331_HDR_VERSION_MASK, AR9331_HDR_VERSION);

Hi Oleksij

This change does not seem to fit with what this patch is doing.

I also think it is wrong. You still need BPDU to pass through a
blocked port, otherwise spanning tree protocol will be unstable.

Andrew

2021-04-03 14:56:51

by Andrew Lunn

[permalink] [raw]
Subject: Re: [PATCH net-next v1 3/9] net: dsa: qca: ar9331: reorder MDIO write sequence

Hi Oleksij

Maybe add a short comment about why the order is important.

> - ret = __ar9331_mdio_write(sbus, AR9331_SW_MDIO_PHY_MODE_REG, reg, val);
> + ret = __ar9331_mdio_write(sbus, AR9331_SW_MDIO_PHY_MODE_REG, reg + 2,
> + val >> 16);
> if (ret < 0)
> goto error;
>
> - ret = __ar9331_mdio_write(sbus, AR9331_SW_MDIO_PHY_MODE_REG, reg + 2,
> - val >> 16);
> + ret = __ar9331_mdio_write(sbus, AR9331_SW_MDIO_PHY_MODE_REG, reg, val);
> if (ret < 0)
> goto error;
>
> return 0;
> +
> error:
> dev_err_ratelimited(&sbus->dev, "Bus error. Failed to write register.\n");
> return ret;

With that:

Reviewed-by: Andrew Lunn <[email protected]>

Andrew





> --
> 2.29.2
>

2021-04-03 15:26:42

by Oleksij Rempel

[permalink] [raw]
Subject: Re: [PATCH net-next v1 2/9] net: dsa: tag_ar9331: detect IGMP and MLD packets

On Sat, Apr 03, 2021 at 04:46:06PM +0300, Vladimir Oltean wrote:
> On Sat, Apr 03, 2021 at 03:26:36PM +0200, Oleksij Rempel wrote:
> > On Sat, Apr 03, 2021 at 04:03:18PM +0300, Vladimir Oltean wrote:
> > > Hi Oleksij,
> > >
> > > On Sat, Apr 03, 2021 at 01:48:41PM +0200, Oleksij Rempel wrote:
> > > > The ar9331 switch is not forwarding IGMP and MLD packets if IGMP
> > > > snooping is enabled. This patch is trying to mimic the HW heuristic to take
> > > > same decisions as this switch would do to be able to tell the linux
> > > > bridge if some packet was prabably forwarded or not.
> > > >
> > > > Signed-off-by: Oleksij Rempel <[email protected]>
> > > > ---
> > >
> > > I am not familiar with IGMP/MLD, therefore I don't really understand
> > > what problem you are trying to solve.
> > >
> > > Your switch has packet traps for IGMP and MLD, ok. So it doesn't forward
> > > them. Must the IGMP/MLD packets be forwarded by an IGMP/MLD snooping
> > > bridge? Which ones and under what circumstances?
> >
> > I'll better refer to the rfc:
> > https://tools.ietf.org/html/rfc4541
>
> Ok, the question might have been a little bit dumb.
> I found this PDF:
> https://www.alliedtelesis.com/sites/default/files/documents/how-alliedware/howto_config_igmp1.pdf
> and it explains that:
> - a snooper floods the Membership Query messages from the network's
> querier towards all ports that are not blocked by STP
> - a snooper forwards all Membership Report messages from a client
> towards the All Groups port (which is how it reaches the querier).
>
> I'm asking this because I just want to understand what the bridge code
> does. Does the code path for IGMP_HOST_MEMBERSHIP_REPORT (for example)
> for a snooper go through should_deliver -> nbp_switchdev_allowed_egress,
> which is what you are affecting here?

yes.

the exact path should depend on this configuration option:
/sys/devices/virtual/net/test/bridge/multicast_snooping

I assume, some optimization can be done by letting DSA know the state
of multicast_snooping.

Off-topic question, this patch set stops to work after rebasing against
latest netdev. I get following warning:
ip l s lan0 master test
RTNETLINK answers: Invalid argumen

Are there some API changes?

Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

2021-04-03 15:27:23

by Andrew Lunn

[permalink] [raw]
Subject: Re: [PATCH net-next v1 5/9] net: dsa: qca: ar9331: add forwarding database support

> +static int ar9331_sw_port_fdb_rmw(struct ar9331_sw_priv *priv,
> + const unsigned char *mac,
> + u8 port_mask_set,
> + u8 port_mask_clr)
> +{
> + port_mask = FIELD_GET(AR9331_SW_AT_DES_PORT, f2);
> + status = FIELD_GET(AR9331_SW_AT_STATUS, f2);
> + if (status > 0 && status < AR9331_SW_AT_STATUS_STATIC) {
> + dev_err_ratelimited(priv->dev, "%s: found existing dynamic entry on %x\n",
> + __func__, port_mask);
> +
> + if (port_mask_set && port_mask_set != port_mask)
> + dev_err_ratelimited(priv->dev, "%s: found existing dynamic entry on %x, replacing it with static on %x\n",
> + __func__, port_mask, port_mask_set);
> + port_mask = 0;
> + } else if (!status && !port_mask_set) {
> + return 0;
> + }

As a generate rule of thumb, use rate limiting where you have no
control of the number of prints, e.g. it is triggered by packet
processing, and there is potentially a lot of them, which could DOS
the box by a remote or unprivileged attacker.

FDB changes should not happen often. Yes, root my be able to DOS the
box by doing bridge fdb add commands in a loop, but only root should
be able to do that.

Plus, i'm not actually sure we should be issuing warnings here. What
does the bridge code do in this case? Is it silent and just does it,
or does it issue a warning?




> +
> + port_mask_new = port_mask & ~port_mask_clr;
> + port_mask_new |= port_mask_set;
> +
> + if (port_mask_new == port_mask &&
> + status == AR9331_SW_AT_STATUS_STATIC) {
> + dev_info(priv->dev, "%s: no need to overwrite existing valid entry on %x\n",
> + __func__, port_mask_new);

This one should probably be dev_dbg().

Andrew

2021-04-03 15:32:23

by Andrew Lunn

[permalink] [raw]
Subject: Re: [PATCH net-next v1 7/9] net: dsa: qca: ar9331: add bridge support

On Sat, Apr 03, 2021 at 01:48:46PM +0200, Oleksij Rempel wrote:
> This switch is providing forwarding matrix, with it we can configure
> individual bridges. Potentially we can configure more then one not VLAN
> based bridge on this HW.
>
> Signed-off-by: Oleksij Rempel <[email protected]>
> ---
> drivers/net/dsa/qca/ar9331.c | 73 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 73 insertions(+)
>
> diff --git a/drivers/net/dsa/qca/ar9331.c b/drivers/net/dsa/qca/ar9331.c
> index b2c22ba924f0..bf9588574205 100644
> --- a/drivers/net/dsa/qca/ar9331.c
> +++ b/drivers/net/dsa/qca/ar9331.c
> @@ -40,6 +40,7 @@
> */
>
> #include <linux/bitfield.h>
> +#include <linux/if_bridge.h>
> #include <linux/module.h>
> #include <linux/of_irq.h>
> #include <linux/of_mdio.h>
> @@ -1134,6 +1135,76 @@ static int ar9331_sw_set_ageing_time(struct dsa_switch *ds,
> val);
> }
>
> +static int ar9331_sw_port_bridge_join(struct dsa_switch *ds, int port,
> + struct net_device *br)
> +{
> + struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
> + struct regmap *regmap = priv->regmap;
> + int port_mask = BIT(priv->cpu_port);
> + int i, ret;
> + u32 val;
> +
> + for (i = 0; i < ds->num_ports; i++) {
> + if (dsa_to_port(ds, i)->bridge_dev != br)
> + continue;
> +
> + if (!dsa_is_user_port(ds, port))
> + continue;
> +
> + val = FIELD_PREP(AR9331_SW_PORT_VLAN_PORT_VID_MEMBER, BIT(port));
> + ret = regmap_set_bits(regmap, AR9331_SW_REG_PORT_VLAN(i), val);
> + if (ret)
> + goto error;
> +
> + if (i != port)
> + port_mask |= BIT(i);
> + }
> +
> + val = FIELD_PREP(AR9331_SW_PORT_VLAN_PORT_VID_MEMBER, port_mask);
> + ret = regmap_update_bits(regmap, AR9331_SW_REG_PORT_VLAN(port),
> + AR9331_SW_PORT_VLAN_PORT_VID_MEMBER, val);
> + if (ret)
> + goto error;
> +
> + return 0;
> +error:
> + dev_err_ratelimited(priv->dev, "%s: error: %i\n", __func__, ret);
> +
> + return ret;
> +}
> +
> +static void ar9331_sw_port_bridge_leave(struct dsa_switch *ds, int port,
> + struct net_device *br)
> +{
> + struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
> + struct regmap *regmap = priv->regmap;
> + int i, ret;
> + u32 val;
> +
> + for (i = 0; i < ds->num_ports; i++) {
> + if (dsa_to_port(ds, i)->bridge_dev != br)
> + continue;
> +
> + if (!dsa_is_user_port(ds, port))
> + continue;
> +
> + val = FIELD_PREP(AR9331_SW_PORT_VLAN_PORT_VID_MEMBER, BIT(port));
> + ret = regmap_clear_bits(regmap, AR9331_SW_REG_PORT_VLAN(i), val);
> + if (ret)
> + goto error;
> + }

Join and leave only seems to differ by:

> + if (i != port)
> + port_mask |= BIT(i);

Maybe refactor the code to add a helper for the identical parts?

Andrew

2021-04-03 16:41:15

by Vladimir Oltean

[permalink] [raw]
Subject: Re: [PATCH net-next v1 2/9] net: dsa: tag_ar9331: detect IGMP and MLD packets

On Sat, Apr 03, 2021 at 05:22:24PM +0200, Oleksij Rempel wrote:
> Off-topic question, this patch set stops to work after rebasing against
> latest netdev. I get following warning:
> ip l s lan0 master test
> RTNETLINK answers: Invalid argumen
>
> Are there some API changes?

Yes, it's likely that you are returning -EINVAL to some of the functions
with which DSA calls you at .port_bridge_join time, see dsa_port_switchdev_sync.

2021-04-03 17:19:10

by Oleksij Rempel

[permalink] [raw]
Subject: Re: [PATCH net-next v1 2/9] net: dsa: tag_ar9331: detect IGMP and MLD packets

Am 03.04.21 um 16:49 schrieb Andrew Lunn:
>> @@ -31,6 +96,13 @@ static struct sk_buff *ar9331_tag_xmit(struct sk_buff *skb,
>> __le16 *phdr;
>> u16 hdr;
>>
>> + if (dp->stp_state == BR_STATE_BLOCKING) {
>> + /* TODO: should we reflect it in the stats? */
>> + netdev_warn_once(dev, "%s:%i dropping blocking packet\n",
>> + __func__, __LINE__);
>> + return NULL;
>> + }
>> +
>> phdr = skb_push(skb, AR9331_HDR_LEN);
>>
>> hdr = FIELD_PREP(AR9331_HDR_VERSION_MASK, AR9331_HDR_VERSION);
>
> Hi Oleksij
>
> This change does not seem to fit with what this patch is doing.

done

> I also think it is wrong. You still need BPDU to pass through a
> blocked port, otherwise spanning tree protocol will be unstable.

We need a better filter, otherwise, in case of software based STP, we are leaking packages on
blocked port. For example DHCP do trigger lots of spam in the kernel log.

I'll drop STP patch for now, it will be better to make a generic soft STP for all switches without
HW offloading. For example ksz9477 is doing SW based STP in similar way.

--
Regards,
Oleksij

2021-04-03 23:52:35

by Vladimir Oltean

[permalink] [raw]
Subject: Re: [PATCH net-next v1 5/9] net: dsa: qca: ar9331: add forwarding database support

On Sat, Apr 03, 2021 at 05:25:16PM +0200, Andrew Lunn wrote:
> > +static int ar9331_sw_port_fdb_rmw(struct ar9331_sw_priv *priv,
> > + const unsigned char *mac,
> > + u8 port_mask_set,
> > + u8 port_mask_clr)
> > +{
> > + port_mask = FIELD_GET(AR9331_SW_AT_DES_PORT, f2);
> > + status = FIELD_GET(AR9331_SW_AT_STATUS, f2);
> > + if (status > 0 && status < AR9331_SW_AT_STATUS_STATIC) {
> > + dev_err_ratelimited(priv->dev, "%s: found existing dynamic entry on %x\n",
> > + __func__, port_mask);
> > +
> > + if (port_mask_set && port_mask_set != port_mask)
> > + dev_err_ratelimited(priv->dev, "%s: found existing dynamic entry on %x, replacing it with static on %x\n",
> > + __func__, port_mask, port_mask_set);
> > + port_mask = 0;
> > + } else if (!status && !port_mask_set) {
> > + return 0;
> > + }
>
> As a generate rule of thumb, use rate limiting where you have no
> control of the number of prints, e.g. it is triggered by packet
> processing, and there is potentially a lot of them, which could DOS
> the box by a remote or unprivileged attacker.
>
> FDB changes should not happen often. Yes, root my be able to DOS the
> box by doing bridge fdb add commands in a loop, but only root should
> be able to do that.

+1
The way I see it, rate limiting should only be done when the user can't
stop the printing from spamming the console, and they just go "argh,
kill it with fire!!!" and throw the box away. As a side note, most of
the time when I can't stop the kernel from printing in a loop, the rate
limit isn't enough to stop me from wanting to throw the box out the
window, but I digress.

> Plus, i'm not actually sure we should be issuing warnings here. What
> does the bridge code do in this case? Is it silent and just does it,
> or does it issue a warning?

:D

What Oleksij doesn't know, I bet, is that he's using the bridge bypass
commands:

bridge fdb add dev lan0 00:01:02:03:04:05

That is the deprecated way of managing FDB entries, and has several
disadvantages such as:
- the bridge software FDB never gets updated with this entry, so other
drivers which might be subscribed to DSA's FDB (imagine a non-DSA
driver having the same logic as our ds->assisted_learning_on_cpu_port)
will never see these FDB entries
- you have to manage duplicates yourself

The correct way to install a static bridge FDB entry is:

bridge fdb add dev lan0 00:01:02:03:04:05 master static

That will error out on duplicates for you.

From my side I would even go as far as deleting the bridge bypass
operations (.ndo_fdb_add and .ndo_fdb_del). The more integration we add
between DSA and the bridge/switchdev, the worse it will be when users
just keep using the bridge bypass. To start that process, I guess we
should start emitting a deprecation warning and then pull the trigger
after a few kernel release cycles.

> > +
> > + port_mask_new = port_mask & ~port_mask_clr;
> > + port_mask_new |= port_mask_set;
> > +
> > + if (port_mask_new == port_mask &&
> > + status == AR9331_SW_AT_STATUS_STATIC) {
> > + dev_info(priv->dev, "%s: no need to overwrite existing valid entry on %x\n",
> > + __func__, port_mask_new);
>
> This one should probably be dev_dbg().

Or deleted, along with the overwrite logic.

2021-04-04 00:03:58

by Vladimir Oltean

[permalink] [raw]
Subject: Re: [PATCH net-next v1 2/9] net: dsa: tag_ar9331: detect IGMP and MLD packets

On Sat, Apr 03, 2021 at 07:14:56PM +0200, Oleksij Rempel wrote:
> Am 03.04.21 um 16:49 schrieb Andrew Lunn:
> >> @@ -31,6 +96,13 @@ static struct sk_buff *ar9331_tag_xmit(struct sk_buff *skb,
> >> __le16 *phdr;
> >> u16 hdr;
> >>
> >> + if (dp->stp_state == BR_STATE_BLOCKING) {
> >> + /* TODO: should we reflect it in the stats? */
> >> + netdev_warn_once(dev, "%s:%i dropping blocking packet\n",
> >> + __func__, __LINE__);
> >> + return NULL;
> >> + }
> >> +
> >> phdr = skb_push(skb, AR9331_HDR_LEN);
> >>
> >> hdr = FIELD_PREP(AR9331_HDR_VERSION_MASK, AR9331_HDR_VERSION);
> >
> > Hi Oleksij
> >
> > This change does not seem to fit with what this patch is doing.
>
> done
>
> > I also think it is wrong. You still need BPDU to pass through a
> > blocked port, otherwise spanning tree protocol will be unstable.
>
> We need a better filter, otherwise, in case of software based STP, we are leaking packages on
> blocked port. For example DHCP do trigger lots of spam in the kernel log.

I have no idea whatsoever what 'software based STP' is, if you have
hardware-accelerated forwarding.

> I'll drop STP patch for now, it will be better to make a generic soft STP for all switches without
> HW offloading. For example ksz9477 is doing SW based STP in similar way.

How about we discuss first about what your switch is not doing properly?
Have you debugged more than just watching the bridge change port states?
As Andrew said, a port needs to accept and send link-local frames
regardless of the STP state. In the BLOCKING state it must send no other
frames and have address learning disabled. Is this what's happening, is
the switch forwarding frames towards a BLOCKING port?

2021-04-04 00:39:17

by Vladimir Oltean

[permalink] [raw]
Subject: Re: [PATCH net-next v1 9/9] net: dsa: qca: ar9331: add vlan support

On Sat, Apr 03, 2021 at 01:48:48PM +0200, Oleksij Rempel wrote:
> This switch provides simple VLAN resolution database for 16 entries (VLANs).
> With this database we can cover typical functionalities as port based
> VLANs, untagged and tagged egress. Port based ingress filtering.
>
> The VLAN database is working on top of forwarding database. So,

Define 'on top'.

> potentially, we can have multiple VLANs on top of multiple bridges.
> Hawing one VLAN on top of multiple bridges will fail on different

s/Hawing/Having/

> levels, most probably DSA framework should warn if some one wont to make

s/wont/wants/
s/some one/someone/

> something likes this.

Finally, why should the DSA framework warn?
Even in the default configuration of two bridges, the default_pvid (1)
will be the same. What problems do you have with that?

In commit 0ee2af4ebbe3 ("net: dsa: set configure_vlan_while_not_filtering
to true by default"), I did not notice that ar9331 does not have VLAN
operations, and I mistakenly set ds->configure_vlan_while_not_filtering
= false for your driver. Could you please delete that line and ensure the
following works?

ip link add br0 type bridge
ip link set lan0 master br0
bridge vlan add dev lan0 vid 100
ip link set br0 type bridge vlan_filtering 1
# make sure you can receive traffic with VLAN 100

>
> Signed-off-by: Oleksij Rempel <[email protected]>
> ---
> drivers/net/dsa/qca/ar9331.c | 255 +++++++++++++++++++++++++++++++++++
> 1 file changed, 255 insertions(+)
>
> +static int ar9331_sw_vt_wait(struct ar9331_sw_priv *priv, u32 *f0)
> +{
> + struct regmap *regmap = priv->regmap;
> +
> + return regmap_read_poll_timeout(regmap,
> + AR9331_SW_REG_VLAN_TABLE_FUNCTION0,
> + *f0, !(*f0 & AR9331_SW_VT0_BUSY),
> + 100, 2000);
> +}
> +
> +static int ar9331_sw_port_vt_rmw(struct ar9331_sw_priv *priv, u16 vid,
> + u8 port_mask_set, u8 port_mask_clr)
> +{
> + struct regmap *regmap = priv->regmap;
> + u32 f0, f1, port_mask = 0, port_mask_new, func;
> + struct ar9331_sw_vlan_db *vdb = NULL;
> + int ret, i;
> +
> + if (!vid)
> + return 0;
> +
> + ret = ar9331_sw_vt_wait(priv, &f0);
> + if (ret)
> + return ret;
> +
> + ret = regmap_write(regmap, AR9331_SW_REG_VLAN_TABLE_FUNCTION0, 0);
> + if (ret)
> + goto error;
> +
> + ret = regmap_write(regmap, AR9331_SW_REG_VLAN_TABLE_FUNCTION1, 0);
> + if (ret)
> + goto error;
> +
> + for (i = 0; i < ARRAY_SIZE(priv->vdb); i++) {
> + if (priv->vdb[i].vid == vid) {
> + vdb = &priv->vdb[i];
> + break;
> + }
> + }
> +
> + ret = regmap_read(regmap, AR9331_SW_REG_VLAN_TABLE_FUNCTION1, &f1);
> + if (ret)
> + return ret;
> +
> + if (vdb) {
> + port_mask = vdb->port_mask;
> + }
> +
> + port_mask_new = port_mask & ~port_mask_clr;
> + port_mask_new |= port_mask_set;
> +
> + if (port_mask_new && port_mask_new == port_mask) {
> + dev_info(priv->dev, "%s: no need to overwrite existing valid entry on %x\n",
> + __func__, port_mask_new);

With VLANs, the bridge is indeed much less strict compared to FDBs, due
to the old API having ranges baked in (which were never used).

That being said, is there actually any value in this message? Would you
mind deleting it (I see how it could annoy a user)?

You might want to look at devlink regions if you want to debug the VLAN
table of the hardware.

> + return 0;
> + }
> +
> + if (port_mask_new) {
> + func = AR9331_SW_VT0_FUNC_LOAD_ENTRY;
> + } else {
> + func = AR9331_SW_VT0_FUNC_PURGE_ENTRY;
> + port_mask_new = port_mask;
> + }
> +
> + if (vdb) {
> + vdb->port_mask = port_mask_new;
> +
> + if (!port_mask_new)
> + vdb->vid = 0;
> + } else {
> + for (i = 0; i < ARRAY_SIZE(priv->vdb); i++) {
> + if (!priv->vdb[i].vid) {
> + vdb = &priv->vdb[i];
> + break;
> + }
> + }
> +
> + if (!vdb) {
> + dev_err_ratelimited(priv->dev, "Local VDB is full\n");

You have a netlink extack at your disposal, use it.

> + return -ENOMEM;
> + }
> + vdb->vid = vid;
> + vdb->port_mask = port_mask_new;
> + }
> +
> + f0 = FIELD_PREP(AR9331_SW_VT0_VID, vid) |
> + FIELD_PREP(AR9331_SW_VT0_FUNC, func) |
> + AR9331_SW_VT0_BUSY;
> + f1 = FIELD_PREP(AR9331_SW_VT1_VID_MEM, port_mask_new) |
> + AR9331_SW_VT1_VALID;
> +
> + ret = regmap_write(regmap, AR9331_SW_REG_VLAN_TABLE_FUNCTION1, f1);
> + if (ret)
> + return ret;
> +
> + ret = regmap_write(regmap, AR9331_SW_REG_VLAN_TABLE_FUNCTION0, f0);
> + if (ret)
> + return ret;
> +
> + ret = ar9331_sw_vt_wait(priv, &f0);
> + if (ret)
> + return ret;
> +
> + if (f0 & AR9331_SW_VT0_FULL_VIO) {
> + /* cleanup error status */
> + regmap_write(regmap, AR9331_SW_REG_VLAN_TABLE_FUNCTION0, 0);
> + dev_err_ratelimited(priv->dev, "%s: can't add new entry, VT is full\n", __func__);

Similar comment as above.

> + return -ENOMEM;
> + }
> +
> + return 0;
> +
> +error:
> + dev_err_ratelimited(priv->dev, "%s: error: %pe\n", __func__,
> + ERR_PTR(ret));
> +
> + return ret;
> +}
> +
> +static int ar9331_port_vlan_set_pvid(struct ar9331_sw_priv *priv, int port,
> + u16 pvid)
> +{
> + struct regmap *regmap = priv->regmap;
> + int ret;
> + u32 mask, val;
> +
> + mask = AR9331_SW_PORT_VLAN_8021Q_MODE |
> + AR9331_SW_PORT_VLAN_FORCE_DEFALUT_VID_EN |
> + AR9331_SW_PORT_VLAN_FORCE_PORT_VLAN_EN;
> + val = AR9331_SW_PORT_VLAN_FORCE_DEFALUT_VID_EN |
> + AR9331_SW_PORT_VLAN_FORCE_PORT_VLAN_EN |
> + FIELD_PREP(AR9331_SW_PORT_VLAN_8021Q_MODE,
> + AR9331_SW_8021Q_MODE_FALLBACK);
> +
> + ret = regmap_update_bits(regmap, AR9331_SW_REG_PORT_VLAN(port),
> + mask, val);
> + if (ret)
> + return ret;
> +
> + return regmap_update_bits(regmap, AR9331_SW_REG_PORT_VLAN(port),
> + AR9331_SW_PORT_VLAN_PORT_VID,
> + FIELD_PREP(AR9331_SW_PORT_VLAN_PORT_VID,
> + pvid));
> +}
> +
> +static int ar9331_port_vlan_add(struct dsa_switch *ds, int port,
> + const struct switchdev_obj_port_vlan *vlan,
> + struct netlink_ext_ack *extack)
> +{
> + struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;

You don't need to cast a void pointer in the C language.

> + struct regmap *regmap = priv->regmap;
> + int ret, mode;
> +
> + ret = ar9331_sw_port_vt_rmw(priv, vlan->vid, BIT(port), 0);
> + if (ret)
> + goto error;
> +
> + if (vlan->flags & BRIDGE_VLAN_INFO_PVID)
> + ret = ar9331_port_vlan_set_pvid(priv, port, vlan->vid);
> +
> + if (ret)
> + goto error;
> +
> + if (vlan->flags & BRIDGE_VLAN_INFO_UNTAGGED)
> + mode = AR9331_SW_PORT_CTRL_EG_VLAN_MODE_STRIP;
> + else
> + mode = AR9331_SW_PORT_CTRL_EG_VLAN_MODE_ADD;
> +
> + ret = regmap_update_bits(regmap, AR9331_SW_REG_PORT_CTRL(port),
> + AR9331_SW_PORT_CTRL_EG_VLAN_MODE, mode);
> + if (ret)
> + goto error;
> +
> + return 0;
> +error:
> + dev_err_ratelimited(priv->dev, "%s: error: %pe\n", __func__,
> + ERR_PTR(ret));
> +
> + return ret;
> +}
> +
> +static int ar9331_port_vlan_del(struct dsa_switch *ds, int port,
> + const struct switchdev_obj_port_vlan *vlan)
> +{
> + struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
> + int ret;
> +
> + ret = ar9331_sw_port_vt_rmw(priv, vlan->vid, 0, BIT(port));
> + if (ret)
> + goto error;
> +
> + return 0;
> +
> +error:
> + dev_err_ratelimited(priv->dev, "%s: error: %pe\n", __func__,
> + ERR_PTR(ret));
> +
> + return ret;
> +}

This looks like a whole lot of boilerplate compared to:

ret = vlan_table_read_modify_write
if (ret)
print_error

return ret

> +
> static const struct dsa_switch_ops ar9331_sw_ops = {
> .get_tag_protocol = ar9331_sw_get_tag_protocol,
> .setup = ar9331_sw_setup,
> @@ -1292,6 +1544,9 @@ static const struct dsa_switch_ops ar9331_sw_ops = {
> .port_bridge_join = ar9331_sw_port_bridge_join,
> .port_bridge_leave = ar9331_sw_port_bridge_leave,
> .port_stp_state_set = ar9331_sw_port_stp_state_set,
> + .port_vlan_filtering = ar9331_port_vlan_filtering,
> + .port_vlan_add = ar9331_port_vlan_add,
> + .port_vlan_del = ar9331_port_vlan_del,
> };
>
> static irqreturn_t ar9331_sw_irq(int irq, void *data)
> --
> 2.29.2
>

2021-04-04 00:48:10

by Andrew Lunn

[permalink] [raw]
Subject: Re: [PATCH net-next v1 5/9] net: dsa: qca: ar9331: add forwarding database support

> > Plus, i'm not actually sure we should be issuing warnings here. What
> > does the bridge code do in this case? Is it silent and just does it,
> > or does it issue a warning?
>
> :D
>
> What Oleksij doesn't know, I bet, is that he's using the bridge bypass
> commands:
>
> bridge fdb add dev lan0 00:01:02:03:04:05
>
> That is the deprecated way of managing FDB entries, and has several
> disadvantages such as:
> - the bridge software FDB never gets updated with this entry, so other
> drivers which might be subscribed to DSA's FDB (imagine a non-DSA
> driver having the same logic as our ds->assisted_learning_on_cpu_port)
> will never see these FDB entries
> - you have to manage duplicates yourself

I was actually meaning a pure software bridge, with unaccelerated
interfaces. It has a dynamic MAC address in its tables, and the user
adds a static. Ideally, we want the same behaviour.

And i think the answer is:

static int fdb_insert(struct net_bridge *br, struct net_bridge_port *source,
const unsigned char *addr, u16 vid)
{
struct net_bridge_fdb_entry *fdb;

if (!is_valid_ether_addr(addr))
return -EINVAL;

fdb = br_fdb_find(br, addr, vid);
if (fdb) {
/* it is okay to have multiple ports with same
* address, just use the first one.
*/
if (test_bit(BR_FDB_LOCAL, &fdb->flags))
return 0;
br_warn(br, "adding interface %s with same address as a received packet (addr:%pM, vlan:%u)\n",
source ? source->dev->name : br->dev->name, addr, vid);
fdb_delete(br, fdb, true);
}

fdb = fdb_create(br, source, addr, vid,
BIT(BR_FDB_LOCAL) | BIT(BR_FDB_STATIC));
if (!fdb)
return -ENOMEM;

fdb_add_hw_addr(br, addr);
fdb_notify(br, fdb, RTM_NEWNEIGH, true);
return 0;
}

So it looks like it warns and then replaces the dynamic entry.

So having the DSA driver also warn is maybe O.K. Having said that, i
don't think any other DSA driver does.

Andrew

2021-04-04 02:22:43

by Florian Fainelli

[permalink] [raw]
Subject: Re: [PATCH net-next v1 3/9] net: dsa: qca: ar9331: reorder MDIO write sequence



On 4/3/2021 04:48, Oleksij Rempel wrote:
> In case of this switch we work with 32bit registers on top of 16bit
> bus. Some registers (for example access to forwarding database) have
> trigger bit on the first 16bit half of request and the result +
> configuration of request in the second half. Without this this patch, we would
> trigger database operation and overwrite result in one run.
>
> To make it work properly, we should do the second part of transfer
> before the first one is done.
>
> So far, this rule seems to work for all registers on this switch.
>
> Signed-off-by: Oleksij Rempel <[email protected]>

Seems like you could send this as a separate bugfix for the "net" tree
along with a Fixes tag?
--
Florian

2021-04-04 02:29:52

by Florian Fainelli

[permalink] [raw]
Subject: Re: [PATCH net-next v1 7/9] net: dsa: qca: ar9331: add bridge support



On 4/3/2021 04:48, Oleksij Rempel wrote:
> This switch is providing forwarding matrix, with it we can configure
> individual bridges. Potentially we can configure more then one not VLAN

s/then/than/

> based bridge on this HW.
>
> Signed-off-by: Oleksij Rempel <[email protected]>
> ---
> drivers/net/dsa/qca/ar9331.c | 73 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 73 insertions(+)
>
> diff --git a/drivers/net/dsa/qca/ar9331.c b/drivers/net/dsa/qca/ar9331.c
> index b2c22ba924f0..bf9588574205 100644
> --- a/drivers/net/dsa/qca/ar9331.c
> +++ b/drivers/net/dsa/qca/ar9331.c
> @@ -40,6 +40,7 @@
> */
>
> #include <linux/bitfield.h>
> +#include <linux/if_bridge.h>
> #include <linux/module.h>
> #include <linux/of_irq.h>
> #include <linux/of_mdio.h>
> @@ -1134,6 +1135,76 @@ static int ar9331_sw_set_ageing_time(struct dsa_switch *ds,
> val);
> }
>
> +static int ar9331_sw_port_bridge_join(struct dsa_switch *ds, int port,
> + struct net_device *br)
> +{
> + struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
> + struct regmap *regmap = priv->regmap;
> + int port_mask = BIT(priv->cpu_port);
> + int i, ret;
> + u32 val;
> +
> + for (i = 0; i < ds->num_ports; i++) {
> + if (dsa_to_port(ds, i)->bridge_dev != br)
> + continue;
> +
> + if (!dsa_is_user_port(ds, port))
> + continue;
> +
> + val = FIELD_PREP(AR9331_SW_PORT_VLAN_PORT_VID_MEMBER, BIT(port));
> + ret = regmap_set_bits(regmap, AR9331_SW_REG_PORT_VLAN(i), val);
> + if (ret)
> + goto error;
> +
> + if (i != port)
> + port_mask |= BIT(i);
> + }
> +
> + val = FIELD_PREP(AR9331_SW_PORT_VLAN_PORT_VID_MEMBER, port_mask);
> + ret = regmap_update_bits(regmap, AR9331_SW_REG_PORT_VLAN(port),
> + AR9331_SW_PORT_VLAN_PORT_VID_MEMBER, val);
> + if (ret)
> + goto error;
> +
> + return 0;
> +error:
> + dev_err_ratelimited(priv->dev, "%s: error: %i\n", __func__, ret);

This is not called more than once per port and per bridge join operation
so I would drop the rate limiting here. With that fixed:

Reviewed-by: Florian Fainelli <[email protected]>
--
Florian

2021-04-04 05:41:07

by Oleksij Rempel

[permalink] [raw]
Subject: Re: [PATCH net-next v1 2/9] net: dsa: tag_ar9331: detect IGMP and MLD packets

Am 04.04.21 um 02:02 schrieb Vladimir Oltean:
> On Sat, Apr 03, 2021 at 07:14:56PM +0200, Oleksij Rempel wrote:
>> Am 03.04.21 um 16:49 schrieb Andrew Lunn:
>>>> @@ -31,6 +96,13 @@ static struct sk_buff *ar9331_tag_xmit(struct sk_buff *skb,
>>>> __le16 *phdr;
>>>> u16 hdr;
>>>>
>>>> + if (dp->stp_state == BR_STATE_BLOCKING) {
>>>> + /* TODO: should we reflect it in the stats? */
>>>> + netdev_warn_once(dev, "%s:%i dropping blocking packet\n",
>>>> + __func__, __LINE__);
>>>> + return NULL;
>>>> + }
>>>> +
>>>> phdr = skb_push(skb, AR9331_HDR_LEN);
>>>>
>>>> hdr = FIELD_PREP(AR9331_HDR_VERSION_MASK, AR9331_HDR_VERSION);
>>>
>>> Hi Oleksij
>>>
>>> This change does not seem to fit with what this patch is doing.
>>
>> done
>>
>>> I also think it is wrong. You still need BPDU to pass through a
>>> blocked port, otherwise spanning tree protocol will be unstable.
>>
>> We need a better filter, otherwise, in case of software based STP, we are leaking packages on
>> blocked port. For example DHCP do trigger lots of spam in the kernel log.
>
> I have no idea whatsoever what 'software based STP' is, if you have
> hardware-accelerated forwarding.

I do not mean hardware-accelerated forwarding, i mean
hardware-accelerated STP port state helpers.

>> I'll drop STP patch for now, it will be better to make a generic soft STP for all switches without
>> HW offloading. For example ksz9477 is doing SW based STP in similar way.
>
> How about we discuss first about what your switch is not doing properly?
> Have you debugged more than just watching the bridge change port states?
> As Andrew said, a port needs to accept and send link-local frames
> regardless of the STP state. In the BLOCKING state it must send no other
> frames and have address learning disabled. Is this what's happening, is
> the switch forwarding frames towards a BLOCKING port?

The switch is not forwarding BPDU frame to the CPU port. So, the linux
bridge will stack by cycling different state of the port where loop was
detected.

--
Regards,
Oleksij

2021-04-04 13:00:45

by Vladimir Oltean

[permalink] [raw]
Subject: Re: [PATCH net-next v1 2/9] net: dsa: tag_ar9331: detect IGMP and MLD packets

On Sun, Apr 04, 2021 at 07:35:26AM +0200, Oleksij Rempel wrote:
> Am 04.04.21 um 02:02 schrieb Vladimir Oltean:
> > On Sat, Apr 03, 2021 at 07:14:56PM +0200, Oleksij Rempel wrote:
> >> Am 03.04.21 um 16:49 schrieb Andrew Lunn:
> >>>> @@ -31,6 +96,13 @@ static struct sk_buff *ar9331_tag_xmit(struct sk_buff *skb,
> >>>> __le16 *phdr;
> >>>> u16 hdr;
> >>>>
> >>>> + if (dp->stp_state == BR_STATE_BLOCKING) {
> >>>> + /* TODO: should we reflect it in the stats? */
> >>>> + netdev_warn_once(dev, "%s:%i dropping blocking packet\n",
> >>>> + __func__, __LINE__);
> >>>> + return NULL;
> >>>> + }
> >>>> +
> >>>> phdr = skb_push(skb, AR9331_HDR_LEN);
> >>>>
> >>>> hdr = FIELD_PREP(AR9331_HDR_VERSION_MASK, AR9331_HDR_VERSION);
> >>>
> >>> Hi Oleksij
> >>>
> >>> This change does not seem to fit with what this patch is doing.
> >>
> >> done
> >>
> >>> I also think it is wrong. You still need BPDU to pass through a
> >>> blocked port, otherwise spanning tree protocol will be unstable.
> >>
> >> We need a better filter, otherwise, in case of software based STP, we are leaking packages on
> >> blocked port. For example DHCP do trigger lots of spam in the kernel log.
> >
> > I have no idea whatsoever what 'software based STP' is, if you have
> > hardware-accelerated forwarding.
>
> I do not mean hardware-accelerated forwarding, i mean
> hardware-accelerated STP port state helpers.

Still no clue what you mean, sorry.

> >> I'll drop STP patch for now, it will be better to make a generic soft STP for all switches without
> >> HW offloading. For example ksz9477 is doing SW based STP in similar way.
> >
> > How about we discuss first about what your switch is not doing properly?
> > Have you debugged more than just watching the bridge change port states?
> > As Andrew said, a port needs to accept and send link-local frames
> > regardless of the STP state. In the BLOCKING state it must send no other
> > frames and have address learning disabled. Is this what's happening, is
> > the switch forwarding frames towards a BLOCKING port?
>
> The switch is not forwarding BPDU frame to the CPU port. So, the linux
> bridge will stack by cycling different state of the port where loop was
> detected.

The switch should not be 'forwarding' BPDU frames to the CPU port, it
should be 'trapping' them. The difference is subtle but important. Often
times switches have an Access Control List which allows them to steal
packets from the normal FDB-based forwarding path. It is probably the
case that your switch needs to be told to treat STP BPDUs specially and
not just 'forward' them.
To confirm whether I'm right or wrong, if you disable STP and send a
packet with MAC DA 01:80:c2:00:00:00 to the switch, will it flood it
towards all ports or will it only send them to the CPU?