kernel/linux.git/Documentation/networking/dsa, branch v5.18

docs: net: dsa: fix minor grammar and punctuation issues

2022-04-03T12:06:11+00:00

Fix a few typos and minor grammatical issues. Signed-off-by: Bjorn Helgaas Signed-off-by: David S. Miller

docs: net: dsa: sja1105: document limitations of tc-flower rule VLAN awareness

2022-02-27T11:06:13+00:00

After change "net: dsa: tag_8021q: replace the SVL bridging with VLAN-unaware IVL bridging", tag_8021q enforces two different pvids on a port, depending on whether it is standalone or in a VLAN-unaware bridge. Up until now, there was a single pvid, represented by dsa_tag_8021q_rx_vid(), and that was used as the VLAN for VLAN-unaware virtual link rules, regardless of whether the port was bridged or standalone. To keep VLAN-unaware virtual links working, we need to follow whether the port is in a bridge or not, and update the VLAN ID from those rules. In fact we can't fully do that. Depending on whether the switch is VLAN-aware or not, we can accept Virtual Link rules with just the MAC DA, or with a MAC DA and a VID. So we already deny changes to the VLAN awareness of the switch. But the VLAN awareness may also change as a result of joining or leaving a bridge. One might say we could just allow the following: a port may leave a VLAN-unaware bridge while it has VLAN-unaware VL (tc-flower) rules, and the driver will update those with the new tag_8021q pvid for standalone mode, but the driver won't accept joining a bridge at all while VL rules were installed in standalone mode. This is sort of a compromise made because leaving a bridge is an operation that cannot be vetoed. But this sort of setup change is not fully supported, either: as mentioned, VLAN filtering changes can also be triggered by leaving a bridge, therefore, the existing veto we have in place for turning VLAN filtering off with VLAN-aware VL rules active still isn't fully effective. I really don't know how to deal with this in a way that produces predictable behavior for user space. Since at the moment, keeping this feature fully functional on constellation changes (not changing the tag_8021q port pvid when joining a bridge) is blocking progress for the DSA FDB isolation, I'd rather document it as a (potentially temporary) limitation and go on without it. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller

dt-bindings: net: dsa: sja1105: update nxp,sja1105.yaml reference

2021-09-17T02:01:42+00:00

Changeset 62568bdbe6f6 ("dt-bindings: net: dsa: sja1105: convert to YAML schema") renamed: Documentation/devicetree/bindings/net/dsa/sja1105.txt to: Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml. Update its cross-reference accordingly. Fixes: 62568bdbe6f6 ("dt-bindings: net: dsa: sja1105: convert to YAML schema") Reviewed-by: Vladimir Oltean Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/994ce6c6358746ff600459822b9f6e336db933c9.1631785820.git.mchehab+huawei@kernel.org

docs: net: dsa: document the new methods for bridge TX forwarding offload

2021-08-22T08:49:04+00:00

Two new methods have been introduced, add some verbiage about what they do. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller

docs: net: dsa: remove references to struct dsa_device_ops::filter

2021-08-22T08:49:04+00:00

This function has disappeared in commit edac6f6332d9 ("Revert "net: dsa: Allow drivers to filter packets they can decode source port from""). Also, since commit 4e50025129ef ("net: dsa: generalize overhead for taggers that use both headers and trailers"), the next paragraph is no longer true (it is still discouraged to do that, but it is now supported, so no point in mentioning it). Delete. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller

docs: net: dsa: sja1105: update list of limitations

2021-08-22T08:49:04+00:00

Remove the paragraphs that talk about the various modes of traffic support, bridging with foreign interfaces, etc etc. There is nothing that the user needs to know now, it should all work out of the box as expected. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller

net: dsa: delete dsa_legacy_fdb_add and dsa_legacy_fdb_del

2021-06-29T17:46:23+00:00

We want to add reference counting for FDB entries in cross-chip topologies, and in order for that to have any chance of working and not be unbalanced (leading to entries which are never deleted), we need to ensure that higher layers are sane, because if they aren't, it's garbage in, garbage out. For example, if we add a bridge FDB entry twice, the bridge properly errors out: $ bridge fdb add dev swp0 00:01:02:03:04:07 master static $ bridge fdb add dev swp0 00:01:02:03:04:07 master static RTNETLINK answers: File exists However, the same thing cannot be said about the bridge bypass operations: $ bridge fdb add dev swp0 00:01:02:03:04:07 $ bridge fdb add dev swp0 00:01:02:03:04:07 $ bridge fdb add dev swp0 00:01:02:03:04:07 $ bridge fdb add dev swp0 00:01:02:03:04:07 $ echo $? 0 But one 'bridge fdb del' is enough to remove the entry, no matter how many times it was added. The bridge bypass operations are impossible to maintain in these circumstances and lack of support for reference counting the cross-chip notifiers is holding us back from making further progress, so just drop support for them. The only way left for users to install static bridge FDB entries is the proper one, using the "master static" flags. With this change, rtnl_fdb_add() falls back to calling ndo_dflt_fdb_add() which uses the duplicate-exclusive variant of dev_uc_add(): dev_uc_add_excl(). Because DSA does not (yet) declare IFF_UNICAST_FLT, this results in us going to promiscuous mode: $ bridge fdb add dev swp0 00:01:02:03:04:05 [ 28.206743] device swp0 entered promiscuous mode $ bridge fdb add dev swp0 00:01:02:03:04:05 RTNETLINK answers: File exists So even if it does not completely fail, there is at least some indication that it is behaving differently from before, and closer to user space expectations, I would argue (the lack of a "local|static" specifier defaults to "local", or "host-only", so dev_uc_add() is a reasonable default implementation). If the generic implementation of .ndo_fdb_add provided by Vlad Yasevich is a proof of anything, it only proves that the implementation provided by DSA was always wrong, by not looking at "ndm->ndm_state & NUD_NOARP" (the "static" flag which means that the FDB entry points outwards) and "ndm->ndm_state & NUD_PERMANENT" (the "local" flag which means that the FDB entry points towards the host). It all used to mean the same thing to DSA. Update the documentation so that the users are not confused about what's going on. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller

Documentation: net: dsa: add details about SJA1110

2021-06-24T19:55:57+00:00

Denote that the new switch generation is supported, detail its pin strapping options (with differences compared to SJA1105) and explain how MDIO access to the internal 100base-T1 and 100base-TX PHYs is performed. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller

net: dsa: generalize overhead for taggers that use both headers and trailers

2021-06-11T19:45:38+00:00

Some really really weird switches just couldn't decide whether to use a normal or a tail tagger, so they just did both. This creates problems for DSA, because we only have the concept of an 'overhead' which can be applied to the headroom or to the tailroom of the skb (like for example during the central TX reallocation procedure), depending on the value of bool tail_tag, but not to both. We need to generalize DSA to cater for these odd switches by transforming the 'overhead / tail_tag' pair into 'needed_headroom / needed_tailroom'. The DSA master's MTU is increased to account for both. The flow dissector code is modified such that it only calls the DSA adjustment callback if the tagger has a non-zero header length. Taggers are trivially modified to declare either needed_headroom or needed_tailroom, based on the tail_tag value that they currently declare. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller

Documentation: networking: dsa: mention that the master is brought up automatically

2021-03-17T19:34:35+00:00

Since commit 9d5ef190e561 ("net: dsa: automatically bring up DSA master when opening user port"), DSA manages the administrative status of the host port automatically. Update the configuration steps to reflect this. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller