1. 21 Oct, 2021 6 commits
    • David S. Miller's avatar
    • Vladimir Oltean's avatar
      net: mscc: ocelot: track the port pvid using a pointer · d4004422
      Vladimir Oltean authored
      Now that we have a list of struct ocelot_bridge_vlan entries, we can
      rewrite the pvid logic to simply point to one of those structures,
      instead of having a separate structure with a "bool valid".
      The NULL pointer will represent the lack of a bridge pvid (not to be
      confused with the lack of a hardware pvid on the port, that is present
      at all times).
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d4004422
    • Vladimir Oltean's avatar
      net: mscc: ocelot: add the local station MAC addresses in VID 0 · bfbab310
      Vladimir Oltean authored
      The ocelot switchdev driver does not include the CPU port in the list of
      flooding destinations for unknown traffic, instead that traffic is
      supposed to match FDB entries to reach the CPU.
      
      The addresses it installs are:
      (a) the station MAC address, in ocelot_probe_port() and later during
          runtime in ocelot_port_set_mac_address(). These are the VLAN-unaware
          addresses. The VLAN-aware addresses are in ocelot_vlan_vid_add().
      (b) multicast addresses added with dev_mc_add() (not bridge host MDB
          entries) in ocelot_mc_sync()
      (c) multicast destination MAC addresses for MRP in ocelot_mrp_save_mac(),
          to make sure those are dropped (not forwarded) by the bridging
          service, just trapped to the CPU
      
      So we can see that the logic is slightly buggy ever since the initial
      commit a556c76a ("net: mscc: Add initial Ocelot switch support").
      This is because, when ocelot_probe_port() runs, the port pvid is 0.
      Then we join a VLAN-aware bridge, the pvid becomes 1, we call
      ocelot_port_set_mac_address(), this learns the new MAC address in VID 1
      (also fails to forget the old one, since it thinks it's in VID 1, but
      that's not so important). Then when we leave the VLAN-aware bridge,
      outside world is unable to ping our new MAC address because it isn't
      learned in VID 0, the VLAN-unaware pvid.
      
      [ note: this is strictly based on static analysis, I don't have hardware
        to test. But there are also many more corner cases ]
      
      The basic idea is that we should have a separation of concerns, and the
      FDB entries used for standalone operation should be managed by the
      driver, and the FDB entries used by the bridging service should be
      managed by the bridge. So the standalone and VLAN-unaware bridge FDB
      entries should not follow the bridge PVID, because that will only be
      active when the bridge is VLAN-aware. So since the port pvid is
      coincidentally zero during probe time, just make those entries
      statically go to VID 0.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bfbab310
    • Vladimir Oltean's avatar
      net: mscc: ocelot: allow a config where all bridge VLANs are egress-untagged · 0da1a1c4
      Vladimir Oltean authored
      At present, the ocelot driver accepts a single egress-untagged bridge
      VLAN, meaning that this sequence of operations:
      
      ip link add br0 type bridge vlan_filtering 1
      ip link set swp0 master br0
      bridge vlan add dev swp0 vid 2 pvid untagged
      
      fails because the bridge automatically installs VID 1 as a pvid & untagged
      VLAN, and vid 2 would be the second untagged VLAN on this port. It is
      necessary to delete VID 1 before proceeding to add VID 2.
      
      This limitation comes from the fact that we operate the port tag, when
      it has an egress-untagged VID, in the OCELOT_PORT_TAG_NATIVE mode.
      The ocelot switches do not have full flexibility and can either have one
      single VID as egress-untagged, or all of them.
      
      There are use cases for having all VLANs as egress-untagged as well, and
      this patch adds support for that.
      
      The change rewrites ocelot_port_set_native_vlan() into a more generic
      ocelot_port_manage_port_tag() function. Because the software bridge's
      state, transmitted to us via switchdev, can become very complex, we
      don't attempt to track all possible state transitions, but instead take
      a more declarative approach and just make ocelot_port_manage_port_tag()
      figure out which more to operate in:
      
      - port is VLAN-unaware: the classified VLAN (internal, unrelated to the
                              802.1Q header) is not inserted into packets on egress
      - port is VLAN-aware:
        - port has tagged VLANs:
          -> port has no untagged VLAN: set up as pure trunk
          -> port has one untagged VLAN: set up as trunk port + native VLAN
          -> port has more than one untagged VLAN: this is an invalid config
             which is rejected by ocelot_vlan_prepare
        - port has no tagged VLANs
          -> set up as pure egress-untagged port
      
      We don't keep the number of tagged and untagged VLANs, we just count the
      structures we keep.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0da1a1c4
    • Vladimir Oltean's avatar
      net: mscc: ocelot: convert the VLAN masks to a list · 90e0aa8d
      Vladimir Oltean authored
      First and foremost, the driver currently allocates a constant sized
      4K * u32 (16KB memory) array for the VLAN masks. However, a typical
      application might not need so many VLANs, so if we dynamically allocate
      the memory as needed, we might actually save some space.
      
      Secondly, we'll need to keep more advanced bookkeeping of the VLANs we
      have, notably we'll have to check how many untagged and how many tagged
      VLANs we have. This will have to stay in a structure, and allocating
      another 16 KB array for that is again a bit too much.
      
      So refactor the bridge VLANs in a linked list of structures.
      
      The hook points inside the driver are ocelot_vlan_member_add() and
      ocelot_vlan_member_del(), which previously used to operate on the
      ocelot->vlan_mask[vid] array element.
      
      ocelot_vlan_member_add() and ocelot_vlan_member_del() used to call
      ocelot_vlan_member_set() to commit to the ocelot->vlan_mask.
      Additionally, we had two calls to ocelot_vlan_member_set() from outside
      those callers, and those were directly from ocelot_vlan_init().
      Those calls do not set up bridging service VLANs, instead they:
      
      - clear the VLAN table on reset
      - set the port pvid to the value used by this driver for VLAN-unaware
        standalone port operation (VID 0)
      
      So now, when we have a structure which represents actual bridge VLANs,
      VID 0 doesn't belong in that structure, since it is not part of the
      bridging layer.
      
      So delete the middle man, ocelot_vlan_member_set(), and let
      ocelot_vlan_init() call directly ocelot_vlant_set_mask() which forgoes
      any data structure and writes directly to hardware, which is all that we
      need.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      90e0aa8d
    • Vladimir Oltean's avatar
      net: mscc: ocelot: add a type definition for REW_TAG_CFG_TAG_CFG · 62a22bcb
      Vladimir Oltean authored
      This is a cosmetic patch which clarifies what are the port tagging
      options for Ocelot switches.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      62a22bcb
  2. 20 Oct, 2021 23 commits
  3. 19 Oct, 2021 11 commits