1. 12 Nov, 2019 34 commits
  2. 11 Nov, 2019 6 commits
    • Xin Long's avatar
      lwtunnel: ignore any TUNNEL_OPTIONS_PRESENT flags set by users · 0c06d166
      Xin Long authored
      TUNNEL_OPTIONS_PRESENT (TUNNEL_GENEVE_OPT|TUNNEL_VXLAN_OPT|
      TUNNEL_ERSPAN_OPT) flags should be set only according to
      tb[LWTUNNEL_IP_OPTS], which is done in ip_tun_parse_opts().
      
      When setting info key.tun_flags, the TUNNEL_OPTIONS_PRESENT
      bits in tb[LWTUNNEL_IP(6)_FLAGS] passed from users should
      be ignored.
      
      While at it, replace all (TUNNEL_GENEVE_OPT|TUNNEL_VXLAN_OPT|
      TUNNEL_ERSPAN_OPT) with 'TUNNEL_OPTIONS_PRESENT'.
      
      Fixes: 3093fbe7 ("route: Per route IP tunnel metadata via lightweight tunnel")
      Fixes: 32a2b002 ("ipv6: route: per route IP tunnel metadata via lightweight tunnel")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0c06d166
    • Xin Long's avatar
      lwtunnel: get nlsize for erspan options properly · 58e8494e
      Xin Long authored
      erspan v1 has OPT_ERSPAN_INDEX while erspan v2 has OPT_ERSPAN_DIR and
      OPT_ERSPAN_HWID attributes, and they require different nlsize when
      dumping.
      
      So this patch is to get nlsize for erspan options properly according
      to erspan version.
      
      Fixes: b0a21810 ("lwtunnel: add options setting and dumping for erspan")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      58e8494e
    • Xin Long's avatar
      lwtunnel: change to use nla_parse_nested on new options · ed02551f
      Xin Long authored
      As the new options added in kernel, all should always use strict
      parsing from the beginning with nla_parse_nested(), instead of
      nla_parse_nested_deprecated().
      
      Fixes: b0a21810 ("lwtunnel: add options setting and dumping for erspan")
      Fixes: edf31cbb ("lwtunnel: add options setting and dumping for vxlan")
      Fixes: 4ece4778 ("lwtunnel: add options setting and dumping for geneve")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ed02551f
    • David S. Miller's avatar
      Merge branch 'Accomodate-DSA-front-end-into-Ocelot' · fe2b8a88
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      Accomodate DSA front-end into Ocelot
      
      After the nice "change-my-mind" discussion about Ocelot, Felix and
      LS1028A (which can be read here: https://lkml.org/lkml/2019/6/21/630),
      we have decided to take the route of reworking the Ocelot implementation
      in a way that is DSA-compatible.
      
      This is a large series, but hopefully is easy enough to digest, since it
      contains mostly code refactoring. What needs to be changed:
      - The struct net_device, phy_device needs to be isolated from Ocelot
        private structures (struct ocelot, struct ocelot_port). These will
        live as 1-to-1 equivalents to struct dsa_switch and struct dsa_port.
      - The function prototypes need to be compatible with DSA (of course,
        struct dsa_switch will become struct ocelot).
      - The CPU port needs to be assigned via a higher-level API, not
        hardcoded in the driver.
      
      What is going to be interesting is that the new DSA front-end of Ocelot
      will need to have features in lockstep with the DSA core itself. At the
      moment, some more advanced tc offloading features of Ocelot (tc-flower,
      etc) are not available in the DSA front-end due to lack of API in the
      DSA core. It also means that Ocelot practically re-implements large
      parts of DSA (although it is not a DSA switch per se) - see the FDB API
      for example.
      
      The code has been only compile-tested on Ocelot, since I don't have
      access to any VSC7514 hardware. It was proven to work on NXP LS1028A,
      which instantiates a DSA derivative of Ocelot. So I would like to ask
      Alex Belloni if you could confirm this series causes no regression on
      the Ocelot MIPS SoC.
      
      The goal is to get this rework upstream as quickly as possible,
      precisely because it is a large volume of code that risks gaining merge
      conflicts if we keep it for too long.
      
      This is but the first chunk of the LS1028A Felix DSA driver upstreaming.
      For those who are interested, the concept can be seen on my private
      Github repo, the user of this reworked Ocelot driver living under
      drivers/net/dsa/vitesse/:
      https://github.com/vladimiroltean/ls1028ardb-linux
      ====================
      Acked-by: default avatarHoratiu Vultur <horatiu.vultur@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fe2b8a88
    • Vladimir Oltean's avatar
      net: mscc: ocelot: don't hardcode the number of the CPU port · c9d2203b
      Vladimir Oltean authored
      VSC7514 is a 10-port switch with 2 extra "CPU ports" (targets in the
      queuing subsystem for terminating traffic locally).
      
      There are 2 issues with hardcoding the CPU port as #10:
      - It is not clear which snippets of the code are configuring something
        for one of the CPU ports, and which snippets are just doing something
        related to the number of physical ports.
      - Actually any physical port can act as a CPU port connected to an
        external CPU (in addition to the local CPU). This is called NPI mode
        (Node Processor Interface) and is the way that the 6-port VSC9959
        (Felix) switch is integrated inside NXP LS1028A (the "local management
        CPU" functionality is not used there).
      
      This patch makes it clear that the ocelot_bridge_stp_state_set function
      operates on the CPU port (by making it an implicit member of the
      bridging domain), and at the same time adds logic for the NPI port (aka
      a physical port) to play the role of a CPU port (it shouldn't be part of
      bridge_fwd_mask, as it's not explicitly enslaved to a bridge).
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c9d2203b
    • Vladimir Oltean's avatar
      net: mscc: ocelot: split assignment of the cpu port into a separate function · 21468199
      Vladimir Oltean authored
      Now that the places that configure routing destinations for the CPU port
      have been marked as such, allow callers to specify their own CPU port
      that is different than ocelot->num_phys_ports. A user will be the Felix
      DSA driver, where the CPU port is one of the physical ports (NPI mode).
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      21468199