[PATCH net-next] net: dsa: Expose tagging protocol to user-space

[PATCH net-next] net: dsa: Expose tagging protocol to user-space

[Florian Fainelli]

There is no way for user-space to know what a given DSA network device's
tagging protocol is. Expose this information through a dsa/tagging
attribute which reflects the tagging protocol currently in use.

This is helpful for configuration (e.g: none behaves dramatically
different wrt. bridges) as well as for packet capture tools when there
is not a proper Ethernet type available.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 Documentation/ABI/testing/sysfs-class-net-dsa |  7 +++
 net/dsa/dsa.c                                 | 43 +++++++++++++++++++
 net/dsa/dsa_priv.h                            |  1 +
 net/dsa/slave.c                               | 28 ++++++++++++
 4 files changed, 79 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-net-dsa

diff --git a/Documentation/ABI/testing/sysfs-class-net-dsa b/Documentation/ABI/testing/sysfs-class-net-dsa
new file mode 100644
index 000000000000..f240221e071e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-net-dsa
@@ -0,0 +1,7 @@
+What:		/sys/class/net/<iface>/tagging
+Date:		August 2018
+KernelVersion:	4.20
+Contact:	netdev@vger.kernel.org
+Description:
+		String indicating the type of tagging protocol used by the
+		DSA slave network device.
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index 9f3209ff7ffd..45f70859f550 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -70,6 +70,49 @@ const struct dsa_device_ops *dsa_device_ops[DSA_TAG_LAST] = {
 	[DSA_TAG_PROTO_NONE] = &none_ops,
 };
 
+const char *dsa_tag_protocol_to_str(const struct dsa_device_ops *ops)
+{
+	const char *protocol_name[DSA_TAG_LAST] = {
+#ifdef CONFIG_NET_DSA_TAG_BRCM
+		[DSA_TAG_PROTO_BRCM] = "brcm",
+#endif
+#ifdef CONFIG_NET_DSA_TAG_BRCM_PREPEND
+		[DSA_TAG_PROTO_BRCM_PREPEND] = "brcm-prepend",
+#endif
+#ifdef CONFIG_NET_DSA_TAG_DSA
+		[DSA_TAG_PROTO_DSA] = "dsa",
+#endif
+#ifdef CONFIG_NET_DSA_TAG_EDSA
+		[DSA_TAG_PROTO_EDSA] = "edsa",
+#endif
+#ifdef CONFIG_NET_DSA_TAG_KSZ
+		[DSA_TAG_PROTO_KSZ] = "ksz",
+#endif
+#ifdef CONFIG_NET_DSA_TAG_LAN9303
+		[DSA_TAG_PROTO_LAN9303] = "lan9303",
+#endif
+#ifdef CONFIG_NET_DSA_TAG_MTK
+		[DSA_TAG_PROTO_MTK] = "mtk",
+#endif
+#ifdef CONFIG_NET_DSA_TAG_QCA
+		[DSA_TAG_PROTO_QCA] = "qca",
+#endif
+#ifdef CONFIG_NET_DSA_TAG_TRAILER
+		[DSA_TAG_PROTO_TRAILER] = "trailer",
+#endif
+		[DSA_TAG_PROTO_NONE] = "none",
+	};
+	unsigned int i;
+
+	BUILD_BUG_ON(ARRAY_SIZE(protocol_name) != DSA_TAG_LAST);
+
+	for (i = 0; i < ARRAY_SIZE(dsa_device_ops); i++)
+		if (ops == dsa_device_ops[i])
+			return protocol_name[i];
+
+	return protocol_name[DSA_TAG_PROTO_NONE];
+};
+
 const struct dsa_device_ops *dsa_resolve_tag_protocol(int tag_protocol)
 {
 	const struct dsa_device_ops *ops;
diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index 3964c6f7a7c0..2868b5bb7e7d 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -86,6 +86,7 @@ struct dsa_slave_priv {
 /* dsa.c */
 const struct dsa_device_ops *dsa_resolve_tag_protocol(int tag_protocol);
 bool dsa_schedule_work(struct work_struct *work);
+const char *dsa_tag_protocol_to_str(const struct dsa_device_ops *ops);
 
 /* legacy.c */
 #if IS_ENABLED(CONFIG_NET_DSA_LEGACY)
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 1c45c1d6d241..3f840b6eea69 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -1058,6 +1058,27 @@ static struct device_type dsa_type = {
 	.name	= "dsa",
 };
 
+static ssize_t tagging_show(struct device *d, struct device_attribute *attr,
+			    char *buf)
+{
+	struct net_device *dev = to_net_dev(d);
+	struct dsa_port *dp = dsa_slave_to_port(dev);
+
+	return sprintf(buf, "%s\n",
+		       dsa_tag_protocol_to_str(dp->cpu_dp->tag_ops));
+}
+static DEVICE_ATTR_RO(tagging);
+
+static struct attribute *dsa_slave_attrs[] = {
+	&dev_attr_tagging.attr,
+	NULL
+};
+
+static const struct attribute_group dsa_group = {
+	.name	= "dsa",
+	.attrs	= dsa_slave_attrs,
+};
+
 static void dsa_slave_phylink_validate(struct net_device *dev,
 				       unsigned long *supported,
 				       struct phylink_link_state *state)
@@ -1353,8 +1374,14 @@ int dsa_slave_create(struct dsa_port *port)
 		goto out_phy;
 	}
 
+	ret = sysfs_create_group(&slave_dev->dev.kobj, &dsa_group);
+	if (ret)
+		goto out_unreg;
+
 	return 0;
 
+out_unreg:
+	unregister_netdev(slave_dev);
 out_phy:
 	rtnl_lock();
 	phylink_disconnect_phy(p->dp->pl);
@@ -1378,6 +1405,7 @@ void dsa_slave_destroy(struct net_device *slave_dev)
 	rtnl_unlock();
 
 	dsa_slave_notify(slave_dev, DSA_PORT_UNREGISTER);
+	sysfs_remove_group(&slave_dev->dev.kobj, &dsa_group);
 	unregister_netdev(slave_dev);
 	phylink_destroy(dp->pl);
 	free_percpu(p->stats64);
-- 
2.17.1

Re: [PATCH net-next] net: dsa: Expose tagging protocol to user-space

[David Miller]

From: Florian Fainelli <f.fainelli@gmail.com>
Date: Fri,  7 Sep 2018 11:09:02 -0700

> There is no way for user-space to know what a given DSA network device's
> tagging protocol is. Expose this information through a dsa/tagging
> attribute which reflects the tagging protocol currently in use.
> 
> This is helpful for configuration (e.g: none behaves dramatically
> different wrt. bridges) as well as for packet capture tools when there
> is not a proper Ethernet type available.
> 
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>

Applied, thanks Florian.

Re: [PATCH net-next] net: dsa: Expose tagging protocol to user-space

[Jiri Pirko]

Fri, Sep 07, 2018 at 08:09:02PM CEST, f.fainelli@gmail.com wrote:
>There is no way for user-space to know what a given DSA network device's
>tagging protocol is. Expose this information through a dsa/tagging
>attribute which reflects the tagging protocol currently in use.
>
>This is helpful for configuration (e.g: none behaves dramatically
>different wrt. bridges) as well as for packet capture tools when there
>is not a proper Ethernet type available.


Hmm, I wonder. It this something that varies between ports of an
individual ASIC? Or is it rather something defined per-ASIC. If so, this
looks more like a devlink-api material.

Re: [PATCH net-next] net: dsa: Expose tagging protocol to user-space

[Andrew Lunn]

On Sat, Sep 08, 2018 at 11:43:31AM +0200, Jiri Pirko wrote:
> Fri, Sep 07, 2018 at 08:09:02PM CEST, f.fainelli@gmail.com wrote:
> >There is no way for user-space to know what a given DSA network device's
> >tagging protocol is. Expose this information through a dsa/tagging
> >attribute which reflects the tagging protocol currently in use.
> >
> >This is helpful for configuration (e.g: none behaves dramatically
> >different wrt. bridges) as well as for packet capture tools when there
> >is not a proper Ethernet type available.
> 
> 
> Hmm, I wonder. It this something that varies between ports of an
> individual ASIC? Or is it rather something defined per-ASIC. If so, this
> looks more like a devlink-api material.

Hi Jiri

This is between the CPU ethernet device and the switch port that
interface is connect to.

For the Marvell devices, any switch port can be connected to the CPU
Ethernet interface, and the same protocol is used. However, some
switches have a special port which should be used to connect to the
CPU ethernet and supports this tagging protocol. If the designer gets
it wrong and uses a different port to connect the CPU, no tagging
protocol can be used, which as Florian indicated, has a big impact on
bridging, etc.

And just to make it more complex, Marvel has two tagging
schemes. Older devices use DSA, newer devices uses EDSA. However, for
the very new devices in the 6390 family, Marvell made a subtle change
to how EDSA works, which broke it, so we had to go back to DSA.

Of the different tagging protocols used by the 50 or so switches Linux
supports, only the EDSA tagging protocol makes use of an
Ethertype. tcpdump knows how to decode these packets. For all the
other tagging protocols, it has no idea, the Ethertype is all messed
up, and it just prints hex. What i think Florian wants to do is stuff
the tagging protocol into the pcap-ng header so that tcpdump knows
what protocol is in use, and can put the correct protocol dissector in
the chain.

And just for completeness, there potentially is a second tagging
scheme when you have multiple switches connected together in a
cluster, but that is internal to the cluster. The CPU is unaware of
it. But if you are snooping on the traffic, you need to know what the
protocol is, so you can decode the frames. In theory, that could be
EDSA or DSA, and can be selected per intra-switch link. In practice,
they are all DSA, and i've not heard of anybody actually snooping this
traffic.

	Andrew