1. 28 Jul, 2021 1 commit
  2. 26 Jul, 2021 12 commits
  3. 25 Jul, 2021 14 commits
  4. 24 Jul, 2021 1 commit
  5. 23 Jul, 2021 12 commits
    • David S. Miller's avatar
      Merge branch '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue · facfbf4f
      David S. Miller authored
      Tony Nguyen says:
      
      ====================
      1GbE Intel Wired LAN Driver Updates 2021-07-23
      
      This series contains updates to igb and e100 drivers.
      
      Grzegorz adds a timeout check to prevent possible infinite loop for igb.
      
      Kees Cook adjusts memcpy() argument to represent the entire structure
      to allow for appropriate bounds checking for igb and e100.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      facfbf4f
    • chongjiapeng's avatar
      net: phy: Remove unused including <linux/version.h> · 94a994d2
      chongjiapeng authored
      Eliminate the follow versioncheck warning:
      
      ./drivers/net/phy/mxl-gpy.c: 9 linux/version.h not needed.
      Reported-by: default avatarAbaci Robot <abaci@linux.alibaba.com>
      Signed-off-by: default avatarchongjiapeng <jiapeng.chong@linux.alibaba.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      94a994d2
    • Krzysztof Kozlowski's avatar
      nfc: port100: constify protocol list array · c65e7025
      Krzysztof Kozlowski authored
      File-scope "port100_protocol" array is read-only and passed as pointer
      to const, so it can be made a const to increase code safety.
      Signed-off-by: default avatarKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c65e7025
    • Kangmin Park's avatar
      mpls: defer ttl decrement in mpls_forward() · 6a6b83ca
      Kangmin Park authored
      Defer ttl decrement to optimize in tx_err case. There is no need
      to decrease ttl in the case of goto tx_err.
      Signed-off-by: default avatarKangmin Park <l4stpr0gr4m@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6a6b83ca
    • Loic Poulain's avatar
      wwan: core: Fix missing RTM_NEWLINK event for default link · 8cc236db
      Loic Poulain authored
      A wwan link created via the wwan_create_default_link procedure is
      never notified to the user (RTM_NEWLINK), causing issues with user
      tools relying on such event to track network links (NetworkManager).
      
      This is because the procedure misses a call to rtnl_configure_link(),
      which sets the link as initialized and notifies the new link (cf
      proper usage in __rtnl_newlink()).
      
      Cc: stable@vger.kernel.org
      Fixes: ca374290 ("wwan: core: support default netdev creation")
      Suggested-by: default avatarSergey Ryazanov <ryazanov.s.a@gmail.com>
      Signed-off-by: default avatarLoic Poulain <loic.poulain@linaro.org>
      Acked-by: default avatarSergey Ryazanov <ryazanov.s.a@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8cc236db
    • Jerin Jacob's avatar
      octeontx2-af: Enhance mailbox trace entry · 3bdba2c7
      Jerin Jacob authored
      Added mailbox id to name translation on trace entry for
      better tracing output.
      
      Before the change:
      otx2_msg_process: [0002:01:00.0] msg:(0x03) error:0
      
      After the change:
      otx2_msg_process: [0002:01:00.0] msg:(DETACH_RESOURCES) error:0
      Signed-off-by: default avatarJerin Jacob <jerinj@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3bdba2c7
    • Kees Cook's avatar
      e100: Avoid memcpy() over-reading of ETH_SS_STATS · cd74f25b
      Kees Cook authored
      In preparation for FORTIFY_SOURCE performing compile-time and run-time
      field bounds checking for memcpy(), memmove(), and memset(), avoid
      intentionally reading across neighboring array fields.
      
      The memcpy() is copying the entire structure, not just the first array.
      Adjust the source argument so the compiler can do appropriate bounds
      checking.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      cd74f25b
    • Kees Cook's avatar
      igb: Avoid memcpy() over-reading of ETH_SS_STATS · c9183f45
      Kees Cook authored
      In preparation for FORTIFY_SOURCE performing compile-time and run-time
      field bounds checking for memcpy(), memmove(), and memset(), avoid
      intentionally reading across neighboring array fields.
      
      The memcpy() is copying the entire structure, not just the first array.
      Adjust the source argument so the compiler can do appropriate bounds
      checking.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Tested-by: default avatarTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      c9183f45
    • Grzegorz Siwik's avatar
      igb: Add counter to i21x doublecheck · 07be39e3
      Grzegorz Siwik authored
      Add failed_counter to i21x_doublecheck(). There is possibility that
      loop will never end.
      With this patch the loop will stop after maximum 3 retries
      to write to MTA_REGISTER
      Signed-off-by: default avatarGrzegorz Siwik <grzegorz.siwik@intel.com>
      Tested-by: default avatarTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      07be39e3
    • David S. Miller's avatar
      Merge branch 'bridge-tx-fwd' · 356ae88f
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      Allow TX forwarding for the software bridge data path to be offloaded to capable devices
      
      On RX, switchdev drivers have the ability to mark packets for the
      software bridge as "already forwarded in hardware" via
      skb->offload_fwd_mark. This instructs the nbp_switchdev_allowed_egress()
      function to perform software forwarding of that packet only to the bridge
      ports that are not in the same hardware domain as the source packet.
      
      This series expands the concept for TX, in the sense that we can trust
      the accelerator to:
      (a) look up its FDB (which is more or less in sync with the software
          bridge FDB) for selecting the destination ports for a packet
      (b) replicate the frame in hardware in case it's a multicast/broadcast,
          instead of the software bridge having to clone it and send the
          clones to each net device one at a time. This reduces the bandwidth
          needed between the CPU and the accelerator, as well as the CPU time
          spent.
      
      This is done by augmenting nbp_switchdev_allowed_egress() to also
      exclude the bridge ports which have the tx_fwd_offload capability if the
      skb has already been transmitted to one port from their hardware domain.
      
      Even though in reality, the software bridge still technically looks up
      the FDB/MDB for every frame, but all skb clones are suppressed, this
      offload specifically requires that the switchdev accelerator looks up
      its FDB/MDB again. It is intended to be used to inject "data plane
      packets" into the hardware as opposed to "control plane packets" which
      target a precise destination port.
      
      Towards that goal, the bridge always provides the TX packets with
      skb->offload_fwd_mark = true with the VLAN tag always present, so that
      the accelerator can forward according to that VLAN broadcast domain.
      
      This work is not intended to cater to switches which can inject control
      plane packets to a bit mask of destination ports. I see that as a more
      difficult task to accomplish with potentially less benefits (it provides
      only replication offload). The reason it is more difficult is that
      struct skb_buff would probably need to be extended to contain a list of
      struct net_devices that the packet must be replicated to. Sending data
      plane packets avoids that issue by keeping the hardware and software FDB
      more or less in sync and looking it up twice.
      
      Additionally, the ability for the software bridge to request data plane
      packets to be sent brings the opportunity for "dumb switches" to support
      traffic termination to/from the bridge. Such switches (DSA or otherwise)
      typically only use control packets for link-local traps, and sending or
      receiving a control packet is an expensive operation.
      
      For this class of switches, this patch series makes the difference
      between supporting and not supporting local IP termination through a
      VLAN-aware bridge, bridging with a foreign interface, bridging with
      software upper interfaces like LAG, etc. So instead of telling them
      "oh, what a dumb switch you are!", we can now tell them "oh, what a
      stark contrast you have between the control and data plane!".
      
      Patches 1-3 tested on Turris MOX (3 mv88e6xxx switches in a daisy chain
      topology) and a second DSA driver to be added soon. Patches 4-5 tested
      only on Turris MOX.
      
      ===========================================================
      
      Changes in v5:
      - make sure the static key is decremented on bridge port unoffload
      - rename functions and variables so that the "tx_fwd_offload" string is
        easy to grep across the git tree
      - simplify DSA core bookkeeping of the bridge_num
      
      ===========================================================
      
      Changes in v4:
      
      The biggest change compared to the previous series is not present in the
      patches, but is rather a lack of them. Previously we were replaying
      switchdev objects on the public notifier chain, but that was a mistake
      in my reasoning and it was reverted for v4. Therefore, we are now
      passing the notifier blocks as arguments to switchdev_bridge_port_offload()
      for all drivers. This alone gets rid of 7 patches compared to v3.
      
      Other changes are:
      - Take more care for the case where mlxsw leaves a VLAN or LAG upper
        that is a bridge port, make sure that switchdev_bridge_port_unoffload()
        gets called for that case
      - A couple of DSA bug fixes
      - Add change logs for all patches
      - Copy all switchdev driver maintainers on the changes relevant to them
      
      ===========================================================
      
      Message for v3:
      https://patchwork.kernel.org/project/netdevbpf/cover/20210712152142.800651-1-vladimir.oltean@nxp.com/
      
      In this submission I have introduced a "native switchdev" driver API to
      signal whether the TX forwarding offload is supported or not. This comes
      after a third person has said that the macvlan offload framework used
      for v2 and v1 was simply too convoluted.
      
      This large patch set is submitted for discussion purposes (it is
      provided in its entirety so it can be applied & tested on net-next).
      It is only minimally tested, and yet I will not copy all switchdev
      driver maintainers until we agree on the viability of this approach.
      
      The major changes compared to v2:
      - The introduction of switchdev_bridge_port_offload() and
        switchdev_bridge_port_unoffload() as two major API changes from the
        perspective of a switchdev driver. All drivers were converted to call
        these.
      - Augment switchdev_bridge_port_{,un}offload to also handle the
        switchdev object replays on port join/leave.
      - Augment switchdev_bridge_port_offload to also signal whether the TX
        forwarding offload is supported.
      
      ===========================================================
      
      Message for v2:
      https://patchwork.kernel.org/project/netdevbpf/cover/20210703115705.1034112-1-vladimir.oltean@nxp.com/
      
      For this series I have taken Tobias' work from here:
      https://patchwork.kernel.org/project/netdevbpf/cover/20210426170411.1789186-1-tobias@waldekranz.com/
      and made the following changes:
      - I collected and integrated (hopefully all of) Nikolay's, Ido's and my
        feedback on the bridge driver changes. Otherwise, the structure of the
        bridge changes is pretty much the same as Tobias left it.
      - I basically rewrote the DSA infrastructure for the data plane
        forwarding offload, based on the commonalities with another switch
        driver for which I implemented this feature (not submitted here)
      - I adapted mv88e6xxx to use the new infrastructure, hopefully it still
        works but I didn't test that
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      356ae88f
    • Tobias Waldekranz's avatar
      net: dsa: tag_dsa: offload the bridge forwarding process · d82f8ab0
      Tobias Waldekranz authored
      Allow the DSA tagger to generate FORWARD frames for offloaded skbs
      sent from a bridge that we offload, allowing the switch to handle any
      frame replication that may be required. This also means that source
      address learning takes place on packets sent from the CPU, meaning
      that return traffic no longer needs to be flooded as unknown unicast.
      Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d82f8ab0
    • Vladimir Oltean's avatar
      net: dsa: mv88e6xxx: map virtual bridges with forwarding offload in the PVT · ce5df689
      Vladimir Oltean authored
      The mv88e6xxx switches have the ability to receive FORWARD (data plane)
      frames from the CPU port and route them according to the FDB. We can use
      this to offload the forwarding process of packets sent by the software
      bridge.
      
      Because DSA supports bridge domain isolation between user ports, just
      sending FORWARD frames is not enough, as they might leak the intended
      broadcast domain of the bridge on behalf of which the packets are sent.
      
      It should be noted that FORWARD frames are also (and typically) used to
      forward data plane packets on DSA links in cross-chip topologies. The
      FORWARD frame header contains the source port and switch ID, and
      switches receiving this frame header forward the packet according to
      their cross-chip port-based VLAN table (PVT).
      
      To address the bridging domain isolation in the context of offloading
      the forwarding on TX, the idea is that we can reuse the parts of the PVT
      that don't have any physical switch mapped to them, one entry for each
      software bridge. The switches will therefore think that behind their
      upstream port lie many switches, all in fact backed up by software
      bridges through tag_dsa.c, which constructs FORWARD packets with the
      right switch ID corresponding to each bridge.
      
      The mapping we use is absolutely trivial: DSA gives us a unique bridge
      number, and we add the number of the physical switches in the DSA switch
      tree to that, to obtain a unique virtual bridge device number to use in
      the PVT.
      Co-developed-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
      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>
      ce5df689