Merge branch 'sja1105-bridge-port-traffic-termination'

Vladimir Oltean says:

====================
Traffic termination for sja1105 ports under VLAN-aware bridge

This set of patches updates the sja1105 DSA driver to be able to send
and receive network stack packets on behalf of a VLAN-aware upper bridge
interface.

The reasons why this has traditionally been a problem are explained in
the "Traffic support" section of Documentation/networking/dsa/sja1105.rst.
(the entire documentation will be revised in a separate patch series).

The limitations that have prevented us from doing this so far have now
been partially lifted by the bridge's ability to send a packet with
skb->offload_fwd_mark = true, which means that the accelerator is
allowed to look up its hardware FDB when sending a packet and deliver it
to those destination ports. Basically skb->dev is now just a conduit to
the switchdev driver's ndo_start_xmit(), and does not guarantee that the
packet will really be transmitted on that port (but it will be
transmitted where it should, nonetheless).

Apart from the ability to perform IP termination on VLAN-aware bridges
on top of sja1105 interfaces, we also gain the following features:
- VLAN-aware software bridging between sja1105 ports and "foreign"
  (non-DSA) interfaces
- software bridging between sja1105 bridge ports, and software LAG
  uppers of sja1105 ports (as long as the bridge is VLAN-aware)

The only things that don't work are:
1. to create an AF_PACKET socket on top of a sja1105 port that is under
   a VLAN-aware bridge. This is because the "imprecise RX" procedure
   selects an RX port for data plane* packets based on the assumption
   that the packet will land in the bridge's data path.  If ebtables
   rules are added to remove some packets from the bridge's data path,
   that assumption will be broken. Nonetheless, this is not a limitation
   that negatively impacts the known use cases with this switch.  If
   there was a way to impose user space restrictions against creating
   AF_PACKET sockets on this particular configuration, I could be
   interested in adding those restrictions, but I think there are other
   known broken configs already which are not checked by the kernel
   today (like for example that the bridge's rx_handler steals packets
   anyway from AF_PACKET sockets with exact-match ptype handlers, as
   opposed to ptype_all which are processed earlier; this is precisely
   the reason why ebtables rules are generally needed to avoid that).
2. to send traffic on behalf of an 8021q upper of a standalone interface,
   while other sja1105 ports are part of a VLAN-aware bridge. This is
   because sja1105 sets ds->vlan_filtering_is_global = true, so we
   cannot make the standalone port ignore the VLAN header from the
   packet on RX, so we cannot make tag_8021q enforce its own pvid for
   the packets belonging to that port's 8021q upper. So we cannot
   determine in the first place that packets come from that port, unless
   we iterate through all 8021q uppers of all ports, and enforce
   uniqueness of VLAN IDs. I am not sure if this is what I want / if it
   is worth it, so currently all 8021q uppers are denied, regardless of
   whether the switch has ports under a VLAN-aware bridge or not
   (otherwise it becomes complicated even to track the state).
   Nonetheless, the VID uniqueness of all 8021q uppers does raise
   another question: what to do with VID 0, which has no 8021q upper,
   but the 8021q module adds it to our RX filter with vlan_vid_add().
   I am honestly not sure what to do. The best I can do is enable a
   hardware bit in sja1105 which reclassifies VID 0 frames to the PVID,
   and they will be sent on the CPU port using either the tag_8021q pvid
   of standalone ports, or the bridge pvid of VLAN-aware ports. So at
   the very least, those packets are still 'kinda' processed as if they
   were untagged, but the VID 0 is lost, though. In my defence, Marvell
   appears to do the same thing with reclassifying VID 0 frames, see
   commit b8b79c414eca ("net: dsa: mv88e6xxx: Fix adding vlan 0").

*Control packets (currently hardcoded in sja1105 as link-local packets
for MAC DA ranges 01-80-c2-xx-xx-xx and 01-1b-19-xx-xx-xx) are received
based on packet traps and their precise source port is always known.

I have taken one patch from Colin because my work conflicts with his,
and integrating it all through the same series avoids that.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>