1. 21 Jun, 2020 22 commits
    • Tao Ren's avatar
      of: mdio: preserve phy dev_flags in of_phy_connect() · 902053f1
      Tao Ren authored
      Replace assignment "=" with OR "|=" for "phy->dev_flags" so "dev_flags"
      configured in phy probe() function can be preserved.
      
      The idea is similar to commit e7312efb ("net: phy: modify assignment
      to OR for dev_flags in phy_attach_direct").
      Signed-off-by: default avatarTao Ren <rentao.bupt@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      902053f1
    • Amritha Nambiar's avatar
      net: Avoid overwriting valid skb->napi_id · 78e57f15
      Amritha Nambiar authored
      This will be useful to allow busy poll for tunneled traffic. In case of
      busy poll for sessions over tunnels, the underlying physical device's
      queues need to be polled.
      
      Tunnels schedule NAPI either via netif_rx() for backlog queue or
      schedule the gro_cell_poll(). netif_rx() propagates the valid skb->napi_id
      to the socket. OTOH, gro_cell_poll() stamps the skb->napi_id again by
      calling skb_mark_napi_id() with the tunnel NAPI which is not a busy poll
      candidate. This was preventing tunneled traffic to use busy poll. A valid
      NAPI ID in the skb indicates it was already marked for busy poll by a
      NAPI driver and hence needs to be copied into the socket.
      Signed-off-by: default avatarAmritha Nambiar <amritha.nambiar@intel.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      78e57f15
    • Gaurav Singh's avatar
      Remove redundant condition in qdisc_graft · 8eaf8d99
      Gaurav Singh authored
      parent cannot be NULL here since its in the else part
      of the if (parent == NULL) condition. Remove the extra
      check on parent pointer.
      Signed-off-by: default avatarGaurav Singh <gaurav1086@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8eaf8d99
    • David S. Miller's avatar
      Merge branch 'Ocelot-Felix-driver-cleanup' · cd399838
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      Ocelot/Felix driver cleanup
      
      Some of the code in the mscc felix and ocelot drivers was added while in
      a bit of a hurry. Let's take a moment and put things in relative order.
      
      First 3 patches are sparse warning fixes.
      
      Patches 4-9 perform some further splitting between mscc_felix,
      mscc_ocelot, and the common hardware library they share. Meaning that
      some code is being moved from the library into just the mscc_ocelot
      module.
      
      Patches 10-12 refactor the naming conventions in the existing VCAP code
      (for tc-flower offload), since we're going to be adding some more code
      for VCAP IS1 (previous tentatives already submitted here:
      https://patchwork.ozlabs.org/project/netdev/cover/20200602051828.5734-1-xiaoliang.yang_1@nxp.com/),
      and that code would be confusing to read and maintain using current
      naming conventions.
      
      No functional modification is intended. I checked that the VCAP IS2 code
      still works by applying a tc ingress filter with an EtherType key and
      'drop' action.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cd399838
    • Vladimir Oltean's avatar
      net: mscc: ocelot: unexpose ocelot_vcap_policer_{add,del} · c73b0ad3
      Vladimir Oltean authored
      Remove the function prototypes from ocelot_police.h and make these
      functions static. We need to move them above their callers. Note that
      moving the implementations to ocelot_police.c is not trivially possible
      due to dependency on is2_entry_set() which is static to ocelot_vcap.c.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c73b0ad3
    • Vladimir Oltean's avatar
      net: mscc: ocelot: generalize the "ACE/ACL" names · aae4e500
      Vladimir Oltean authored
      Access Control Lists (and their respective Access Control Entries) are
      specifically entries in the VCAP IS2, the security enforcement block,
      according to the documentation.
      Let's rename the structures and functions to something more generic, so
      that VCAP IS1 structures (which would otherwise have to be called
      Ingress Classification Entries) can reuse the same code without
      confusion.
      
      Some renaming that was done:
      
      struct ocelot_ace_rule -> struct ocelot_vcap_filter
      struct ocelot_acl_block -> struct ocelot_vcap_block
      enum ocelot_ace_type -> enum ocelot_vcap_key_type
      struct ocelot_ace_vlan -> struct ocelot_vcap_key_vlan
      enum ocelot_ace_action -> enum ocelot_vcap_action
      struct ocelot_ace_stats -> struct ocelot_vcap_stats
      enum ocelot_ace_type -> enum ocelot_vcap_key_type
      struct ocelot_ace_frame_* -> struct ocelot_vcap_key_*
      
      No functional change is intended.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aae4e500
    • Vladimir Oltean's avatar
      net: mscc: ocelot: rename ocelot_ace.{c, h} to ocelot_vcap.{c,h} · 3c83654f
      Vladimir Oltean authored
      Access Control Lists (and their respective Access Control Entries) are
      specifically entries in the VCAP IS2, the security enforcement block,
      according to the documentation.
      
      Let's rename the files that deal with generic operations on the VCAP
      TCAM, so that VCAP IS1 and ES0 can reuse the same code without
      confusion.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3c83654f
    • Vladimir Oltean's avatar
      net: mscc: ocelot: move net_device related functions to ocelot_net.c · 9c90eea3
      Vladimir Oltean authored
      The ocelot hardware library shouldn't contain too much net_device
      specific code, since it is shared with DSA which abstracts that
      structure away. So much as much of this code as possible into the
      mscc_ocelot driver and outside of the common library.
      
      We're making an exception for MDB and LAG code. That is not yet exported
      to DSA, but when it will, most of the code that's already in ocelot.c
      will remain there. So, there's no point in moving code to ocelot_net.c
      just to move it back later.
      
      We could have moved all net_device code to ocelot_vsc7514.c directly,
      but let's operate under the assumption that if a new switchdev ocelot
      driver gets added, it'll define its SoC-specific stuff in a new
      ocelot_vsc*.c file and it'll reuse the rest of the code.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9c90eea3
    • Vladimir Oltean's avatar
      net: mscc: ocelot: move ocelot_regs.c into ocelot_vsc7514.c · d9feb904
      Vladimir Oltean authored
      ocelot_regs.c actually shouldn't be part of the common library. It
      describes the register map of the VSC7514 switch. The way ocelot
      switches work, they'll have highly optimized register maps, so another
      SoC will likely have the same registers but laid out completely
      different in memory (so there's little room for reusing this structure).
      So move it to ocelot_vsc7514.c instead.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d9feb904
    • Vladimir Oltean's avatar
      net: mscc: ocelot: rename MSCC_OCELOT_SWITCH_OCELOT to MSCC_OCELOT_SWITCH · 14addfb6
      Vladimir Oltean authored
      Putting 'ocelot' in the config's name twice just to say that 'it's the
      ocelot driver running on the ocelot SoC' is a bit confusing. Instead,
      it's just the ocelot driver. Now that we've renamed the previous symbol
      that was holding the MSCC_OCELOT_SWITCH_OCELOT into *_LIB (because
      that's what it is), we're free to use this name for the driver.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      14addfb6
    • Vladimir Oltean's avatar
      net: mscc: ocelot: convert MSCC_OCELOT_SWITCH into a library · f4d0323b
      Vladimir Oltean authored
      Hide the CONFIG_MSCC_OCELOT_SWITCH option from users. It is meant to be
      only a hardware library which is selected by the drivers that use it
      (ocelot, felix).
      
      Since it is "selected" from Kconfig, all its dependencies are manually
      transferred to the driver that selects it. This is because "select" in
      Kconfig language is a bit of a mess, and doesn't handle dependencies of
      selected options quite right.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f4d0323b
    • Vladimir Oltean's avatar
      net: mscc: ocelot: rename module to mscc_ocelot · 56583862
      Vladimir Oltean authored
      mscc_ocelot is a slightly better name for a module than ocelot_board or
      ocelot_vsc7514 is, so let's use that.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      56583862
    • Vladimir Oltean's avatar
      net: mscc: ocelot: rename ocelot_board.c to ocelot_vsc7514.c · 589aa6e7
      Vladimir Oltean authored
      To follow the model of felix and seville where we have one
      platform-specific file, rename this file to the actual SoC it serves.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      589aa6e7
    • Vladimir Oltean's avatar
      net: mscc: ocelot: access EtherType using __be16 · ff4b0bc6
      Vladimir Oltean authored
      Get rid of sparse "cast to restricted __be16" warnings.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ff4b0bc6
    • Vladimir Oltean's avatar
      net: mscc: ocelot: use plain int when interacting with TCAM tables · 7eb5c96a
      Vladimir Oltean authored
      sparse is rightfully complaining about the fact that:
      
      warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
         26 |   __builtin_constant_p((l) > (h)), (l) > (h), 0)))
            |                            ^
      note: in expansion of macro ‘GENMASK_INPUT_CHECK’
         39 |  (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
            |   ^~~~~~~~~~~~~~~~~~~
      note: in expansion of macro ‘GENMASK’
        127 |   mask = GENMASK(width, 0);
            |          ^~~~~~~
      
      So replace the variables that go into GENMASK with plain, signed integer
      types.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7eb5c96a
    • Vladimir Oltean's avatar
      net: dsa: felix: make vcap is2 keys and actions static · 3ab4ceb6
      Vladimir Oltean authored
      Get rid of some sparse warnings.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3ab4ceb6
    • David S. Miller's avatar
      Merge branch 'Strict-mode-for-VRF' · 60cb8d3d
      David S. Miller authored
      Andrea Mayer says:
      
      ====================
      Strict mode for VRF
      
      This patch set adds the new "strict mode" functionality to the Virtual
      Routing and Forwarding infrastructure (VRF). Hereafter we discuss the
      requirements and the main features of the "strict mode" for VRF.
      
      On VRF creation, it is necessary to specify the associated routing table used
      during the lookup operations. Currently, there is no mechanism that avoids
      creating multiple VRFs sharing the same routing table. In other words, it is not
      possible to force a one-to-one relationship between a specific VRF and the table
      associated with it.
      
      The "strict mode" imposes that each VRF can be associated to a routing table
      only if such routing table is not already in use by any other VRF.
      In particular, the strict mode ensures that:
      
       1) given a specific routing table, the VRF (if exists) is uniquely identified;
       2) given a specific VRF, the related table is not shared with any other VRF.
      
      Constraints (1) and (2) force a one-to-one relationship between each VRF and the
      corresponding routing table.
      
      The strict mode feature is designed to be network-namespace aware and it can be
      directly enabled/disabled acting on the "strict_mode" parameter.
      Read and write operations are carried out through the classic sysctl command on
      net.vrf.strict_mode path, i.e: sysctl -w net.vrf.strict_mode=1.
      
      Only two distinct values {0,1} are accepted by the strict_mode parameter:
      
       - with strict_mode=0, multiple VRFs can be associated with the same table.
         This is the (legacy) default kernel behavior, the same that we experience
         when the strict mode patch set is not applied;
      
       - with strict_mode=1, the one-to-one relationship between the VRFs and the
         associated tables is guaranteed. In this configuration, the creation of a VRF
         which refers to a routing table already associated with another VRF fails and
         the error is returned to the user.
      
      The kernel keeps track of the associations between a VRF and the routing table
      during the VRF setup, in the "management" plane. Therefore, the strict mode does
      not impact the performance or the intrinsic functionality of the data plane in
      any way.
      
      When the strict mode is active it is always possible to disable the strict mode,
      while the reverse operation is not always allowed.
      Setting the strict_mode parameter to 0 is equivalent to removing the one-to-one
      constraint between any single VRF and its associated routing table.
      
      Conversely, if the strict mode is disabled and there are multiple VRFs that
      refer to the same routing table, then it is prohibited to set the strict_mode
      parameter to 1. In this configuration, any attempt to perform the operation will
      lead to an error and it will be reported to the user.
      To enable strict mode once again (by setting the strict_mode parameter to 1),
      you must first remove all the VRFs that share common tables.
      
      There are several use cases which can take advantage from the introduction of
      the strict mode feature. In particular, the strict mode allows us to:
      
        i) guarantee the proper functioning of some applications which deal with
           routing protocols;
      
       ii) perform some tunneling decap operations which require to use specific
           routing tables for segregating and forwarding the traffic.
      
      Considering (i), the creation of different VRFs that point to the same table
      leads to the situation where two different routing entities believe they have
      exclusive access to the same table. This leads to the situation where different
      routing daemons can conflict for gaining routes control due to overlapping
      tables. By enabling strict mode it is possible to prevent this situation which
      often occurs due to incorrect configurations done by the users.
      The ability to enable/disable the strict mode functionality does not depend on
      the tool used for configuring the networking. In essence, the strict mode patch
      solves, at the kernel level, what some other patches [1] had tried to solve at
      the userspace level (using only iproute2) with all the related problems.
      
      Considering (ii), the introduction of the strict mode functionality allows us
      implementing the SRv6 End.DT4 behavior. Such behavior terminates a SR tunnel and
      it forwards the IPv4 traffic according to the routes present in the routing
      table supplied during the configuration. The SRv6 End.DT4 can be realized
      exploiting the routing capabilities made available by the VRF infrastructure.
      This behavior could leverage a specific VRF for forcing the traffic to be
      forwarded in accordance with the routes available in the VRF table.
      Anyway, in order to make the End.DT4 properly work, it must be guaranteed that
      the table used for the route lookup operations is bound to one and only one VRF.
      In this way, it is possible to use the table for uniquely retrieving the
      associated VRF and for routing packets.
      
      I would like to thank David Ahern for his constant and valuable support during
      the design and development phases of this patch set.
      
      Comments, suggestions and improvements are very welcome!
      ====================
      Acked-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      60cb8d3d
    • Andrea Mayer's avatar
      selftests: add selftest for the VRF strict mode · 8735e6ea
      Andrea Mayer authored
      The new strict mode functionality is tested in different configurations and
      on different network namespaces.
      Signed-off-by: default avatarAndrea Mayer <andrea.mayer@uniroma2.it>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8735e6ea
    • Andrea Mayer's avatar
      vrf: add l3mdev registration for table to VRF device lookup · a59a8ffd
      Andrea Mayer authored
      During the initialization phase of the VRF module, the callback for table
      to VRF device lookup is registered in l3mdev.
      Signed-off-by: default avatarAndrea Mayer <andrea.mayer@uniroma2.it>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a59a8ffd
    • Andrea Mayer's avatar
      vrf: add sysctl parameter for strict mode · 33306f1a
      Andrea Mayer authored
      Add net.vrf.strict_mode sysctl parameter.
      
      When net.vrf.strict_mode=0 (default) it is possible to associate multiple
      VRF devices to the same table. Conversely, when net.vrf.strict_mode=1 a
      table can be associated to a single VRF device.
      
      When switching from net.vrf.strict_mode=0 to net.vrf.strict_mode=1, a check
      is performed to verify that all tables have at most one VRF associated,
      otherwise the switch is not allowed.
      
      The net.vrf.strict_mode parameter is per network namespace.
      Signed-off-by: default avatarAndrea Mayer <andrea.mayer@uniroma2.it>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      33306f1a
    • Andrea Mayer's avatar
      vrf: track associations between VRF devices and tables · c8baec38
      Andrea Mayer authored
      Add the data structures and the processing logic to keep track of the
      associations between VRF devices and routing tables.
      When a VRF is instantiated, it needs to refer to a given routing table.
      For each table, we explicitly keep track of the existing VRFs that refer to
      the table.
      Signed-off-by: default avatarAndrea Mayer <andrea.mayer@uniroma2.it>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c8baec38
    • Andrea Mayer's avatar
      l3mdev: add infrastructure for table to VRF mapping · 49042c22
      Andrea Mayer authored
      Add infrastructure to l3mdev (the core code for Layer 3 master devices) in
      order to find out the corresponding VRF device for a given table id.
      Therefore, the l3mdev implementations:
       - can register a callback that returns the device index of the l3mdev
         associated with a given table id;
       - can offer the lookup function (table to VRF device).
      Signed-off-by: default avatarAndrea Mayer <andrea.mayer@uniroma2.it>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      49042c22
  2. 20 Jun, 2020 13 commits
  3. 19 Jun, 2020 5 commits