<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/net/dsa, branch v6.3</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v6.3</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v6.3'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2023-03-30T18:32:46Z</updated>
<entry>
<title>net: dsa: sync unicast and multicast addresses for VLAN filters too</title>
<updated>2023-03-30T18:32:46Z</updated>
<author>
<name>Vladimir Oltean</name>
<email>vladimir.oltean@nxp.com</email>
</author>
<published>2023-03-29T15:18:21Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=64fdc5f341db01200e33105265d4b8450122a82e'/>
<id>urn:sha1:64fdc5f341db01200e33105265d4b8450122a82e</id>
<content type='text'>
If certain conditions are met, DSA can install all necessary MAC
addresses on the CPU ports as FDB entries and disable flooding towards
the CPU (we call this RX filtering).

There is one corner case where this does not work.

ip link add br0 type bridge vlan_filtering 1 &amp;&amp; ip link set br0 up
ip link set swp0 master br0 &amp;&amp; ip link set swp0 up
ip link add link swp0 name swp0.100 type vlan id 100
ip link set swp0.100 up &amp;&amp; ip addr add 192.168.100.1/24 dev swp0.100

Traffic through swp0.100 is broken, because the bridge turns on VLAN
filtering in the swp0 port (causing RX packets to be classified to the
FDB database corresponding to the VID from their 802.1Q header), and
although the 8021q module does call dev_uc_add() towards the real
device, that API is VLAN-unaware, so it only contains the MAC address,
not the VID; and DSA's current implementation of ndo_set_rx_mode() is
only for VID 0 (corresponding to FDB entries which are installed in an
FDB database which is only hit when the port is VLAN-unaware).

It's interesting to understand why the bridge does not turn on
IFF_PROMISC for its swp0 bridge port, and it may appear at first glance
that this is a regression caused by the logic in commit 2796d0c648c9
("bridge: Automatically manage port promiscuous mode."). After all,
a bridge port needs to have IFF_PROMISC by its very nature - it needs to
receive and forward frames with a MAC DA different from the bridge
ports' MAC addresses.

While that may be true, when the bridge is VLAN-aware *and* it has a
single port, there is no real reason to enable promiscuity even if that
is an automatic port, with flooding and learning (there is nowhere for
packets to go except to the BR_FDB_LOCAL entries), and this is how the
corner case appears. Adding a second automatic interface to the bridge
would make swp0 promisc as well, and would mask the corner case.

Given the dev_uc_add() / ndo_set_rx_mode() API is what it is (it doesn't
pass a VLAN ID), the only way to address that problem is to install host
FDB entries for the cartesian product of RX filtering MAC addresses and
VLAN RX filters.

Fixes: 7569459a52c9 ("net: dsa: manage flooding on the CPU ports")
Signed-off-by: Vladimir Oltean &lt;vladimir.oltean@nxp.com&gt;
Reviewed-by: Simon Horman &lt;simon.horman@corigine.com&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Link: https://lore.kernel.org/r/20230329151821.745752-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: dsa: tag_brcm: legacy: fix daisy-chained switches</title>
<updated>2023-03-22T00:29:13Z</updated>
<author>
<name>Álvaro Fernández Rojas</name>
<email>noltari@gmail.com</email>
</author>
<published>2023-03-19T09:55:40Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=032a954061afd4b7426c3eb6bfd2952ef1e9a384'/>
<id>urn:sha1:032a954061afd4b7426c3eb6bfd2952ef1e9a384</id>
<content type='text'>
When BCM63xx internal switches are connected to switches with a 4-byte
Broadcom tag, it does not identify the packet as VLAN tagged, so it adds one
based on its PVID (which is likely 0).
Right now, the packet is received by the BCM63xx internal switch and the 6-byte
tag is properly processed. The next step would to decode the corresponding
4-byte tag. However, the internal switch adds an invalid VLAN tag after the
6-byte tag and the 4-byte tag handling fails.
In order to fix this we need to remove the invalid VLAN tag after the 6-byte
tag before passing it to the 4-byte tag decoding.

Fixes: 964dbf186eaa ("net: dsa: tag_brcm: add support for legacy tags")
Signed-off-by: Álvaro Fernández Rojas &lt;noltari@gmail.com&gt;
Reviewed-by: Michal Swiatkowski &lt;michal.swiatkowski@linux.intel.com&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Link: https://lore.kernel.org/r/20230319095540.239064-1-noltari@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: dsa: report rx_bytes unadjusted for ETH_HLEN</title>
<updated>2023-03-20T09:09:53Z</updated>
<author>
<name>Vladimir Oltean</name>
<email>vladimir.oltean@nxp.com</email>
</author>
<published>2023-03-17T23:19:00Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=a8eff03545d4cef12ae66a1905627c1818a0f81a'/>
<id>urn:sha1:a8eff03545d4cef12ae66a1905627c1818a0f81a</id>
<content type='text'>
We collect the software statistics counters for RX bytes (reported to
/proc/net/dev and to ethtool -S $dev | grep 'rx_bytes: ") at a time when
skb-&gt;len has already been adjusted by the eth_type_trans() -&gt;
skb_pull_inline(skb, ETH_HLEN) call to exclude the L2 header.

This means that when connecting 2 DSA interfaces back to back and
sending 1 packet with length 100, the sending interface will report
tx_bytes as incrementing by 100, and the receiving interface will report
rx_bytes as incrementing by 86.

Since accounting for that in scripts is quirky and is something that
would be DSA-specific behavior (requiring users to know that they are
running on a DSA interface in the first place), the proposal is that we
treat it as a bug and fix it.

This design bug has always existed in DSA, according to my analysis:
commit 91da11f870f0 ("net: Distributed Switch Architecture protocol
support") also updates skb-&gt;dev-&gt;stats.rx_bytes += skb-&gt;len after the
eth_type_trans() call. Technically, prior to Florian's commit
a86d8becc3f0 ("net: dsa: Factor bottom tag receive functions"), each and
every vendor-specific tagging protocol driver open-coded the same bug,
until the buggy code was consolidated into something resembling what can
be seen now. So each and every driver should have its own Fixes: tag,
because of their different histories until the convergence point.
I'm not going to do that, for the sake of simplicity, but just blame the
oldest appearance of buggy code.

There are 2 ways to fix the problem. One is the obvious way, and the
other is how I ended up doing it. Obvious would have been to move
dev_sw_netstats_rx_add() one line above eth_type_trans(), and below
skb_push(skb, ETH_HLEN). But DSA processing is not as simple as that.
We count the bytes after removing everything DSA-related from the
packet, to emulate what the packet's length was, on the wire, when the
user port received it.

When eth_type_trans() executes, dsa_untag_bridge_pvid() has not run yet,
so in case the switch driver requests this behavior - commit
412a1526d067 ("net: dsa: untag the bridge pvid from rx skbs") has the
details - the obvious variant of the fix wouldn't have worked, because
the positioning there would have also counted the not-yet-stripped VLAN
header length, something which is absent from the packet as seen on the
wire (there it may be untagged, whereas software will see it as
PVID-tagged).

Fixes: f613ed665bb3 ("net: dsa: Add support for 64-bit statistics")
Signed-off-by: Vladimir Oltean &lt;vladimir.oltean@nxp.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: dsa: don't error out when drivers return ETH_DATA_LEN in .port_max_mtu()</title>
<updated>2023-03-16T17:39:42Z</updated>
<author>
<name>Vladimir Oltean</name>
<email>vladimir.oltean@nxp.com</email>
</author>
<published>2023-03-14T18:24:04Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=636e8adf7878eab3614250234341bde45537f47a'/>
<id>urn:sha1:636e8adf7878eab3614250234341bde45537f47a</id>
<content type='text'>
Currently, when dsa_slave_change_mtu() is called on a user port where
dev-&gt;max_mtu is 1500 (as returned by ds-&gt;ops-&gt;port_max_mtu()), the code
will stumble upon this check:

	if (new_master_mtu &gt; mtu_limit)
		return -ERANGE;

because new_master_mtu is adjusted for the tagger overhead but mtu_limit
is not.

But it would be good if the logic went through, for example if the DSA
master really depends on an MTU adjustment to accept DSA-tagged frames.

To make the code pass through the check, we need to adjust mtu_limit for
the overhead as well, if the minimum restriction was caused by the DSA
user port's MTU (dev-&gt;max_mtu). A DSA user port MTU and a DSA master MTU
are always offset by the protocol overhead.

Currently no drivers return 1500 .port_max_mtu(), but this is only
temporary and a bug in itself - mv88e6xxx should have done that, but
since commit b9c587fed61c ("dsa: mv88e6xxx: Include tagger overhead when
setting MTU for DSA and CPU ports") it no longer does. This is a
preparation for fixing that.

Fixes: bfcb813203e6 ("net: dsa: configure the MTU for switch ports")
Signed-off-by: Vladimir Oltean &lt;vladimir.oltean@nxp.com&gt;
Reviewed-by: Simon Horman &lt;simon.horman@corigine.com&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: dsa: use NL_SET_ERR_MSG_WEAK_MOD() more consistently</title>
<updated>2023-02-04T03:23:32Z</updated>
<author>
<name>Vladimir Oltean</name>
<email>vladimir.oltean@nxp.com</email>
</author>
<published>2023-02-02T14:03:54Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d795527d50796b18c08462188e555139bdd6f967'/>
<id>urn:sha1:d795527d50796b18c08462188e555139bdd6f967</id>
<content type='text'>
Now that commit 028fb19c6ba7 ("netlink: provide an ability to set
default extack message") provides a weak function that doesn't override
an existing extack message provided by the driver, it makes sense to use
it also for LAG and HSR offloading, not just for bridge offloading.

Also consistently put the message string on a separate line, to reduce
line length from 92 to 84 characters.

Signed-off-by: Vladimir Oltean &lt;vladimir.oltean@nxp.com&gt;
Reviewed-by: Simon Horman &lt;simon.horman@corigine.com&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Link: https://lore.kernel.org/r/20230202140354.3158129-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: dsa: Use sysfs_emit() to instead of sprintf()</title>
<updated>2023-02-02T14:28:59Z</updated>
<author>
<name>Bo Liu</name>
<email>liubo03@inspur.com</email>
</author>
<published>2023-02-01T08:14:38Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=b18ea3d9d214dfb23b0b6bd2acc121cb0d0fa2c5'/>
<id>urn:sha1:b18ea3d9d214dfb23b0b6bd2acc121cb0d0fa2c5</id>
<content type='text'>
Follow the advice of the Documentation/filesystems/sysfs.rst and show()
should only use sysfs_emit() or sysfs_emit_at() when formatting the
value to be returned to user space.

Signed-off-by: Bo Liu &lt;liubo03@inspur.com&gt;
Link: https://lore.kernel.org/r/20230201081438.3151-1-liubo03@inspur.com
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
</content>
</entry>
<entry>
<title>netlink: provide an ability to set default extack message</title>
<updated>2023-02-02T05:04:09Z</updated>
<author>
<name>Leon Romanovsky</name>
<email>leonro@nvidia.com</email>
</author>
<published>2023-01-31T13:31:57Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=028fb19c6ba743ed308ba99ac325afa968795e0f'/>
<id>urn:sha1:028fb19c6ba743ed308ba99ac325afa968795e0f</id>
<content type='text'>
In netdev common pattern, extack pointer is forwarded to the drivers
to be filled with error message. However, the caller can easily
overwrite the filled message.

Instead of adding multiple "if (!extack-&gt;_msg)" checks before any
NL_SET_ERR_MSG() call, which appears after call to the driver, let's
add new macro to common code.

[1] https://lore.kernel.org/all/Y9Irgrgf3uxOjwUm@unreal
Reviewed-by: Simon Horman &lt;simon.horman@corigine.com&gt;
Reviewed-by: Nikolay Aleksandrov &lt;razor@blackwall.org&gt;
Signed-off-by: Leon Romanovsky &lt;leonro@nvidia.com&gt;
Link: https://lore.kernel.org/r/6993fac557a40a1973dfa0095107c3d03d40bec1.1675171790.git.leon@kernel.org
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: dsa: microchip: enable port queues for tc mqprio</title>
<updated>2023-01-24T06:12:35Z</updated>
<author>
<name>Arun Ramadoss</name>
<email>arun.ramadoss@microchip.com</email>
</author>
<published>2023-01-20T05:21:34Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=e30f33a5f5c74f278feaa57517d851874dfc640f'/>
<id>urn:sha1:e30f33a5f5c74f278feaa57517d851874dfc640f</id>
<content type='text'>
LAN937x family of switches has 8 queues per port where the KSZ switches
has 4 queues per port. By default, only one queue per port is enabled.
The queues are configurable in 2, 4 or 8. This patch add 8 number of
queues for LAN937x and 4 for other switches.
In the tag_ksz.c file, prioirty of the packet is queried using the skb
buffer and the corresponding value is updated in the tag.

Signed-off-by: Arun Ramadoss &lt;arun.ramadoss@microchip.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: dsa: add plumbing for changing and getting MAC merge layer state</title>
<updated>2023-01-23T12:44:18Z</updated>
<author>
<name>Vladimir Oltean</name>
<email>vladimir.oltean@nxp.com</email>
</author>
<published>2023-01-19T12:27:00Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=5f6c2d498ad97cf9f85b81c0fbb205abbcdfe3f8'/>
<id>urn:sha1:5f6c2d498ad97cf9f85b81c0fbb205abbcdfe3f8</id>
<content type='text'>
The DSA core is in charge of the ethtool_ops of the net devices
associated with switch ports, so in case a hardware driver supports the
MAC merge layer, DSA must pass the callbacks through to the driver.
Add support for precisely that.

Signed-off-by: Vladimir Oltean &lt;vladimir.oltean@nxp.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: dsa: microchip: ptp: move pdelay_rsp correction field to tail tag</title>
<updated>2023-01-13T08:40:41Z</updated>
<author>
<name>Christian Eggers</name>
<email>ceggers@arri.de</email>
</author>
<published>2023-01-10T08:49:26Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=a32190b154bde4a3bf2fddb9367aec49be09b15d'/>
<id>urn:sha1:a32190b154bde4a3bf2fddb9367aec49be09b15d</id>
<content type='text'>
For PDelay_Resp messages we will likely have a negative value in the
correction field. The switch hardware cannot correctly update such
values (produces an off by one error in the UDP checksum), so it must be
moved to the time stamp field in the tail tag. Format of the correction
field is 48 bit ns + 16 bit fractional ns.  After updating the
correction field, clone is no longer required hence it is freed.

Signed-off-by: Christian Eggers &lt;ceggers@arri.de&gt;
Co-developed-by: Arun Ramadoss &lt;arun.ramadoss@microchip.com&gt;
Signed-off-by: Arun Ramadoss &lt;arun.ramadoss@microchip.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
