1. 13 May, 2020 24 commits
  2. 12 May, 2020 16 commits
    • William Tu's avatar
      erspan: Check IFLA_GRE_ERSPAN_VER is set. · 51fa960d
      William Tu authored
      Add a check to make sure the IFLA_GRE_ERSPAN_VER is provided by users.
      
      Fixes: f989d546 ("erspan: Add type I version 0 support.")
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarWilliam Tu <u9012063@gmail.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      51fa960d
    • David S. Miller's avatar
      Merge branch 'Traffic-support-for-dsa_8021q-in-vlan_filtering-1-mode' · 113cb8ff
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      Traffic support for dsa_8021q in vlan_filtering=1 mode
      
      This series is an attempt to support as much as possible in terms of
      traffic I/O from the network stack with the only dsa_8021q user thus
      far, sja1105.
      
      The hardware doesn't support pushing a second VLAN tag to packets that
      are already tagged, so our only option is to combine the dsa_8021q with
      the user tag into a single tag and decode that on the CPU.
      
      The assumption is that there is a type of use cases for which 7 VLANs
      per port are more than sufficient, and that there's another type of use
      cases where the full 4096 entries are barely enough. Those use cases are
      very different from one another, so I prefer trying to give both the
      best experience by creating this best_effort_vlan_filtering knob to
      select the mode in which they want to operate in.
      
      v2 was submitted here:
      https://patchwork.ozlabs.org/project/netdev/cover/20200511135338.20263-1-olteanv@gmail.com/
      
      v1 was submitted here:
      https://patchwork.ozlabs.org/project/netdev/cover/20200510164255.19322-1-olteanv@gmail.com/
      
      Changes in v3:
      Patch 01/15:
      - Rename again to configure_vlan_while_not_filtering, and add a helper
        function for skipping VLAN configuration.
      Patch 03/15:
      - Remove sja1105_can_use_vlan_as_tags from driver code.
      Patch 06/15:
      - Adapt sja1105 driver to the second variable name change.
      Patch 08/15:
      - Provide an implementation of sja1105_can_use_vlan_as_tags as part of
        the tagger and not as part of the switch driver. So we have to look at
        the skb only, and not at the VLAN awareness state.
      
      Changes in v2:
      Patch 01/15:
      - Rename variable from vlan_bridge_vtu to configure_vlans_while_disabled.
      Patch 03/15:
      - Be much more thorough, and make sure that things like virtual links
        and FDB operations still work properly.
      Patch 05/15:
      - Free the vlan lists on teardown.
      - Simplify sja1105_classify_vlan: only look at priv->expect_dsa_8021q.
      - Keep vid 1 in the list of dsa_8021q VLANs, to make sure that untagged
        packets transmitted from the stack, like PTP, continue to work in
        VLAN-unaware mode.
      Patch 06/15:
      - Adapt to vlan_bridge_vtu variable name change.
      Patch 11/15:
      - In sja1105_best_effort_vlan_filtering_set, get the vlan_filtering
        value of each port instead of just one time for port 0. Normally this
        shouldn't matter, but it avoids issues when port 0 is disabled in
        device tree.
      Patch 14/14:
      - Only do anything in sja1105_build_subvlans and in
        sja1105_build_crosschip_subvlans when operating in
        SJA1105_VLAN_BEST_EFFORT state. This avoids installing VLAN retagging
        rules in unaware mode, which would cost us a penalty in terms of
        usable frame memory.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      113cb8ff
    • Vladimir Oltean's avatar
    • Vladimir Oltean's avatar
      net: dsa: sja1105: implement VLAN retagging for dsa_8021q sub-VLANs · 3f01c91a
      Vladimir Oltean authored
      Expand the delta commit procedure for VLANs with additional logic for
      treating bridge_vlans in the newly introduced operating mode,
      SJA1105_VLAN_BEST_EFFORT.
      
      For every bridge VLAN on every user port, a sub-VLAN index is calculated
      and retagging rules are installed towards a dsa_8021q rx_vid that
      encodes that sub-VLAN index. This way, the tagger can identify the
      original VLANs.
      
      Extra care is taken for VLANs to still work as intended in cross-chip
      scenarios. Retagging may have unintended consequences for these because
      a sub-VLAN encoding that works for the CPU does not make any sense for a
      front-panel port.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3f01c91a
    • Vladimir Oltean's avatar
      net: dsa: sja1105: implement a common frame memory partitioning function · aaa270c6
      Vladimir Oltean authored
      There are 2 different features that require some reserved frame memory
      space: VLAN retagging and virtual links. Create a central function that
      modifies the static config and ensures frame memory is never
      overcommitted.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aaa270c6
    • Vladimir Oltean's avatar
      net: dsa: sja1105: add packing ops for the Retagging Table · 88cac0fa
      Vladimir Oltean authored
      The Retagging Table is an optional feature that allows the switch to
      match frames against a {ingress port, egress port, vid} rule and change
      their VLAN ID. The retagged frames are by default clones of the original
      ones (since the hardware-foreseen use case was to mirror traffic for
      debugging purposes and to tag it with a special VLAN for this purpose),
      but we can force the original frames to be dropped by removing the
      pre-retagging VLAN from the port membership list of the egress port.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      88cac0fa
    • Vladimir Oltean's avatar
      net: dsa: sja1105: add a new best_effort_vlan_filtering devlink parameter · 2cafa72e
      Vladimir Oltean authored
      This devlink parameter enables the handling of DSA tags when enslaved to
      a bridge with vlan_filtering=1. There are very good reasons to want
      this, but there are also very good reasons for not enabling it by
      default. So a devlink param named best_effort_vlan_filtering, currently
      driver-specific and exported only by sja1105, is used to configure this.
      
      In practice, this is perhaps the way that most users are going to use
      the switch in. It assumes that no more than 7 VLANs are needed per port.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2cafa72e
    • Vladimir Oltean's avatar
      net: dsa: tag_sja1105: implement sub-VLAN decoding · 84eeb5d4
      Vladimir Oltean authored
      Create a subvlan_map as part of each port's tagger private structure.
      This keeps reverse mappings of bridge-to-dsa_8021q VLAN retagging rules.
      
      Note that as of this patch, this piece of code is never engaged, due to
      the fact that the driver hasn't installed any retagging rule, so we'll
      always see packets with a subvlan code of 0 (untagged).
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      84eeb5d4
    • Vladimir Oltean's avatar
      net: dsa: tag_8021q: support up to 8 VLANs per port using sub-VLANs · 3eaae1d0
      Vladimir Oltean authored
      For switches that support VLAN retagging, such as sja1105, we extend
      dsa_8021q by encoding a "sub-VLAN" into the remaining 3 free bits in the
      dsa_8021q tag.
      
      A sub-VLAN is nothing more than a number in the range 0-7, which serves
      as an index into a per-port driver lookup table. The sub-VLAN value of
      zero means that traffic is untagged (this is also backwards-compatible
      with dsa_8021q without retagging).
      
      The switch should be configured to retag VLAN-tagged traffic that gets
      transmitted towards the CPU port (and towards the CPU only). Example:
      
      bridge vlan add dev sw1p0 vid 100
      
      The switch retags frames received on port 0, going to the CPU, and
      having VID 100, to the VID of 1104 (0x0450). In dsa_8021q language:
      
       | 11  | 10  |  9  |  8  |  7  |  6  |  5  |  4  |  3  |  2  |  1  |  0  |
       +-----------+-----+-----------------+-----------+-----------------------+
       |    DIR    | SVL |    SWITCH_ID    |  SUBVLAN  |          PORT         |
       +-----------+-----+-----------------+-----------+-----------------------+
      
      0x0450 means:
       - DIR = 0b01: this is an RX VLAN
       - SUBVLAN = 0b001: this is subvlan #1
       - SWITCH_ID = 0b001: this is switch 1 (see the name "sw1p0")
       - PORT = 0b0000: this is port 0 (see the name "sw1p0")
      
      The driver also remembers the "1 -> 100" mapping. In the hotpath, if the
      sub-VLAN from the tag encodes a non-untagged frame, this mapping is used
      to create a VLAN hwaccel tag, with the value of 100.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3eaae1d0
    • Vladimir Oltean's avatar
      net: dsa: sja1105: prepare tagger for handling DSA tags and VLAN simultaneously · 38b5beea
      Vladimir Oltean authored
      In VLAN-unaware mode, sja1105 uses VLAN tags with a custom TPID of
      0xdadb. While in the yet-to-be introduced best_effort_vlan_filtering
      mode, it needs to work with normal VLAN TPID values.
      
      A complication arises when we must transmit a VLAN-tagged packet to the
      switch when it's in VLAN-aware mode. We need to construct a packet with
      2 VLAN tags, and the switch will use the outer header for routing and
      pop it on egress. But sadly, here the 2 hardware generations don't
      behave the same:
      
      - E/T switches won't pop an ETH_P_8021AD tag on egress, it seems
        (packets will remain double-tagged).
      - P/Q/R/S switches will drop a packet with 2 ETH_P_8021Q tags (it looks
        like it tries to prevent VLAN hopping).
      
      But looks like the reverse is also true:
      
      - E/T switches have no problem popping the outer tag from packets with
        2 ETH_P_8021Q tags.
      - P/Q/R/S will have no problem popping a single tag even if that is
        ETH_P_8021AD.
      
      So it is clear that if we want the hardware to work with dsa_8021q
      tagging in VLAN-aware mode, we need to send different TPIDs depending on
      revision. Keep that information in priv->info->qinq_tpid.
      
      The per-port tagger structure will hold an xmit_tpid value that depends
      not only upon the qinq_tpid, but also upon the VLAN awareness state
      itself (in case we must transmit using 0xdadb).
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      38b5beea
    • Vladimir Oltean's avatar
      net: dsa: sja1105: exit sja1105_vlan_filtering when called multiple times · cfa36b1f
      Vladimir Oltean authored
      VLAN filtering is a global property for sja1105, and that means that we
      rely on the DSA core to not call us more than once.
      
      But we need to introduce some per-port state for the tagger, namely the
      xmit_tpid, and the best place to do that is where the xmit_tpid changes,
      namely in sja1105_vlan_filtering. So at the moment, exit early from the
      function to avoid unnecessarily resetting the switch for each port call.
      Then we'll change the xmit_tpid prior to the early exit in the next
      patch.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cfa36b1f
    • Vladimir Oltean's avatar
      net: dsa: sja1105: allow VLAN configuration from the bridge in all states · fa83e5d9
      Vladimir Oltean authored
      Let the DSA core call our .port_vlan_add methods every time the bridge
      layer requests so. We will deal internally with saving/restoring VLANs
      depending on our VLAN awareness state.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fa83e5d9
    • Vladimir Oltean's avatar
      net: dsa: sja1105: save/restore VLANs using a delta commit method · ec5ae610
      Vladimir Oltean authored
      Managing the VLAN table that is present in hardware will become very
      difficult once we add a third operating state
      (best_effort_vlan_filtering). That is because correct cleanup (not too
      little, not too much) becomes virtually impossible, when VLANs can be
      added from the bridge layer, from dsa_8021q for basic tagging, for
      cross-chip bridging, as well as retagging rules for sub-VLANs and
      cross-chip sub-VLANs. So we need to rethink VLAN interaction with the
      switch in a more scalable way.
      
      In preparation for that, use the priv->expect_dsa_8021q boolean to
      classify any VLAN request received through .port_vlan_add or
      .port_vlan_del towards either one of 2 internal lists: bridge VLANs and
      dsa_8021q VLANs.
      
      Then, implement a central sja1105_build_vlan_table method that creates a
      VLAN configuration from scratch based on the 2 lists of VLANs kept by
      the driver, and based on the VLAN awareness state. Currently, if we are
      VLAN-unaware, install the dsa_8021q VLANs, otherwise the bridge VLANs.
      
      Then, implement a delta commit procedure that identifies which VLANs
      from this new configuration are actually different from the config
      previously committed to hardware. We apply the delta through the dynamic
      configuration interface (we don't reset the switch). The result is that
      the hardware should see the exact sequence of operations as before this
      patch.
      
      This also helps remove the "br" argument passed to
      dsa_8021q_crosschip_bridge_join, which it was only using to figure out
      whether it should commit the configuration back to us or not, based on
      the VLAN awareness state of the bridge. We can simplify that, by always
      allowing those VLANs inside of our dsa_8021q_vlans list, and committing
      those to hardware when necessary.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ec5ae610
    • Vladimir Oltean's avatar
      net: dsa: sja1105: deny alterations of dsa_8021q VLANs from the bridge · 60b33aeb
      Vladimir Oltean authored
      At the moment, this can never happen. The 2 modes that we operate in do
      not permit that:
      
       - SJA1105_VLAN_UNAWARE: we are guarded from bridge VLANs added by the
         user by the DSA core. We will later lift this restriction by setting
         ds->vlan_bridge_vtu = true, and that is where we'll need it.
      
       - SJA1105_VLAN_FILTERING_FULL: in this mode, dsa_8021q configuration is
         disabled. So the user is free to add these VLANs in the 1024-3071
         range.
      
      The reason for the patch is that we'll introduce a third VLAN awareness
      state, where both dsa_8021q as well as the bridge are going to call our
      .port_vlan_add and .port_vlan_del methods.
      
      For that, we need a good way to discriminate between the 2. The easiest
      (and less intrusive way for upper layers) is to recognize the fact that
      dsa_8021q configurations are always driven by our driver - we _know_
      when a .port_vlan_add method will be called from dsa_8021q because _we_
      initiated it.
      
      So introduce an expect_dsa_8021q boolean which is only used, at the
      moment, for blacklisting VLANs in range 1024-3071 in the modes when
      dsa_8021q is active.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      60b33aeb
    • Vladimir Oltean's avatar
      net: dsa: sja1105: keep the VLAN awareness state in a driver variable · 7f14937f
      Vladimir Oltean authored
      Soon we'll add a third operating mode to the driver. Introduce a
      vlan_state to make things more easy to manage, and use it where
      applicable.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7f14937f
    • Vladimir Oltean's avatar
      net: dsa: tag_8021q: introduce a vid_is_dsa_8021q helper · 1f66b0f0
      Vladimir Oltean authored
      This function returns a boolean denoting whether the VLAN passed as
      argument is part of the 1024-3071 range that the dsa_8021q tagging
      scheme uses.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1f66b0f0