From: Horatiu Vultur <horatiu.vultur@microchip.com>
To: <alexandre.belloni@bootlin.com>, <UNGLinuxDriver@microchip.com>,
<davem@davemloft.net>, <andrew@lunn.ch>,
<allan.nielsen@microchip.com>, <jiri@resnulli.us>,
<ivecera@redhat.com>, <f.fainelli@gmail.com>,
<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Cc: Horatiu Vultur <horatiu.vultur@microchip.com>
Subject: [PATCH v3 2/2] net: mscc: Implement promisc mode.
Date: Thu, 29 Aug 2019 11:22:29 +0200 [thread overview]
Message-ID: <1567070549-29255-3-git-send-email-horatiu.vultur@microchip.com> (raw)
In-Reply-To: <1567070549-29255-1-git-send-email-horatiu.vultur@microchip.com>
When a port is added to the bridge, the port is added in promisc mode. But
the HW is capable of switching the frames therefore is not needed for the
port to be added in promisc mode. In case a user space application requires
for the port to enter promisc mode then is it needed to enter the promisc
mode.
Therefore listen in when the promiscuity on a dev is change and when the
port enters or leaves a bridge. Having this information it is possible to
know when to set the port in promisc mode and when not:
If the port is part of bridge and promiscuity > 1 or if the port is not
part of bridge and promiscuity is > 0 then add then add the port in promisc
mode otherwise don't.
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
---
drivers/net/ethernet/mscc/ocelot.c | 47 ++++++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/drivers/net/ethernet/mscc/ocelot.c b/drivers/net/ethernet/mscc/ocelot.c
index 4d1bce4..292fcc1 100644
--- a/drivers/net/ethernet/mscc/ocelot.c
+++ b/drivers/net/ethernet/mscc/ocelot.c
@@ -1294,6 +1294,37 @@ static void ocelot_port_attr_mc_set(struct ocelot_port *port, bool mc)
ocelot_write_gix(ocelot, val, ANA_PORT_CPU_FWD_CFG, port->chip_port);
}
+static void ocelot_port_attr_promisc_set(struct ocelot_port *port,
+ unsigned int promisc,
+ bool is_bridge_port)
+{
+ struct ocelot *ocelot = port->ocelot;
+ u32 val;
+
+ val = ocelot_read_gix(ocelot, ANA_PORT_CPU_FWD_CFG, port->chip_port);
+
+ /* When a port is added to a bridge, the port is added in promisc mode,
+ * by calling the function 'ndo_set_rx_mode'. But the HW is capable
+ * of switching the frames therefore is not needed for the port to
+ * enter in promisc mode.
+ * But a port needs to be added in promisc mode if an application
+ * requires it(pcap library). Therefore listen when the
+ * dev->promiscuity is change and when the port is added or removed from
+ * the bridge. Using this information, calculate if the promisc mode
+ * is required in the following way:
+ */
+ if (!is_bridge_port && promisc > 0) {
+ val |= ANA_PORT_CPU_FWD_CFG_CPU_SRC_COPY_ENA;
+ } else {
+ if (is_bridge_port && promisc > 1)
+ val |= ANA_PORT_CPU_FWD_CFG_CPU_SRC_COPY_ENA;
+ else
+ val &= ~(ANA_PORT_CPU_FWD_CFG_CPU_SRC_COPY_ENA);
+ }
+
+ ocelot_write_gix(ocelot, val, ANA_PORT_CPU_FWD_CFG, port->chip_port);
+}
+
static int ocelot_port_attr_set(struct net_device *dev,
const struct switchdev_attr *attr,
struct switchdev_trans *trans)
@@ -1316,6 +1347,10 @@ static int ocelot_port_attr_set(struct net_device *dev,
case SWITCHDEV_ATTR_ID_BRIDGE_MC_DISABLED:
ocelot_port_attr_mc_set(ocelot_port, !attr->u.mc_disabled);
break;
+ case SWITCHDEV_ATTR_ID_PORT_PROMISCUITY:
+ ocelot_port_attr_promisc_set(ocelot_port, dev->promiscuity,
+ netif_is_bridge_port(dev));
+ break;
default:
err = -EOPNOTSUPP;
break;
@@ -1688,6 +1723,18 @@ static int ocelot_netdevice_port_event(struct net_device *dev,
ocelot_vlan_port_apply(ocelot_port->ocelot,
ocelot_port);
+
+ /* In case the port is added or removed from the bridge
+ * is it needed to recaulculate the promiscuity. The
+ * reason is that when a port leaves the bridge first
+ * it decrease the promiscuity and then the flag
+ * IFF_BRIDGE_PORT is removed from dev. Therefor the
+ * function ocelot_port_attr_promisc is called with
+ * the wrong arguments.
+ */
+ ocelot_port_attr_promisc_set(ocelot_port,
+ dev->promiscuity,
+ info->linking);
}
if (netif_is_lag_master(info->upper_dev)) {
if (info->linking)
--
2.7.4
prev parent reply other threads:[~2019-08-29 9:24 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-29 9:22 [PATCH v3 0/2] net: core: Notify on changes to dev->promiscuity Horatiu Vultur
2019-08-29 9:22 ` [PATCH v3 1/2] " Horatiu Vultur
2019-08-29 9:51 ` Jiri Pirko
2019-08-29 10:56 ` Horatiu Vultur
2019-08-29 12:18 ` Jiri Pirko
2019-08-29 12:44 ` Horatiu Vultur
2019-08-29 12:55 ` Ivan Vecera
2019-08-29 13:15 ` Andrew Lunn
2019-08-29 13:39 ` Ivan Vecera
2019-08-29 13:15 ` Horatiu Vultur
2019-08-29 13:26 ` Andrew Lunn
2019-08-29 13:49 ` Jiri Pirko
2019-08-29 14:37 ` Andrew Lunn
2019-08-29 17:57 ` Ido Schimmel
2019-08-29 18:29 ` Andrew Lunn
2019-08-29 19:36 ` Ido Schimmel
2019-08-29 22:12 ` David Miller
2019-08-30 5:39 ` Jiri Pirko
2019-08-30 6:02 ` David Miller
2019-08-30 6:36 ` Jiri Pirko
2019-08-30 6:54 ` Ivan Vecera
2019-08-30 7:13 ` David Miller
2019-08-30 7:12 ` David Miller
2019-08-30 7:21 ` Jiri Pirko
2019-08-30 7:32 ` David Miller
2019-08-30 8:01 ` Jiri Pirko
2019-09-02 17:42 ` Allan W. Nielsen
2019-09-02 17:51 ` Jiri Pirko
2019-09-02 18:05 ` Allan W. Nielsen
2019-09-02 18:45 ` Jiri Pirko
2019-09-03 6:13 ` Ido Schimmel
2019-09-03 8:14 ` Allan W. Nielsen
2019-09-08 10:15 ` Ido Schimmel
2019-08-30 9:43 ` Ido Schimmel
2019-08-31 19:35 ` Andrew Lunn
2019-08-31 20:47 ` Ido Schimmel
2019-09-01 18:48 ` Andrew Lunn
2019-09-02 17:55 ` Allan W. Nielsen
2019-09-01 6:54 ` Jiri Pirko
2019-08-29 22:10 ` David Miller
2019-08-29 22:08 ` David Miller
2019-08-30 6:13 ` Jiri Pirko
2019-08-30 6:18 ` David Miller
2019-08-30 7:26 ` Ivan Vecera
2019-08-29 9:22 ` Horatiu Vultur [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1567070549-29255-3-git-send-email-horatiu.vultur@microchip.com \
--to=horatiu.vultur@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=allan.nielsen@microchip.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=ivecera@redhat.com \
--cc=jiri@resnulli.us \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®