1. 15 Dec, 2017 24 commits
    • William Tu's avatar
      ip6_gre: add erspan v2 support · 94d7d8f2
      William Tu authored
      Similar to support for ipv4 erspan, this patch adds
      erspan v2 to ip6erspan tunnel.
      Signed-off-by: default avatarWilliam Tu <u9012063@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      94d7d8f2
    • William Tu's avatar
      net: erspan: introduce erspan v2 for ip_gre · f551c91d
      William Tu authored
      The patch adds support for erspan version 2.  Not all features are
      supported in this patch.  The SGT (security group tag), GRA (timestamp
      granularity), FT (frame type) are set to fixed value.  Only hardware
      ID and direction are configurable.  Optional subheader is also not
      supported.
      Signed-off-by: default avatarWilliam Tu <u9012063@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f551c91d
    • William Tu's avatar
      net: erspan: refactor existing erspan code · 1d7e2ed2
      William Tu authored
      The patch refactors the existing erspan implementation in order
      to support erspan version 2, which has additional metadata.  So, in
      stead of having one 'struct erspanhdr' holding erspan version 1,
      breaks it into 'struct erspan_base_hdr' and 'struct erspan_metadata'.
      Signed-off-by: default avatarWilliam Tu <u9012063@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1d7e2ed2
    • David S. Miller's avatar
      Merge branch 'nfp-ethtool-flash-updates' · 4650b751
      David S. Miller authored
      Jakub Kicinski says:
      
      ====================
      nfp: ethtool flash updates
      
      Dirk says:
      
      This series adds the ability to update the control FW with ethtool.
      
      It should be noted that the locking scheme here is to release the RTNL
      lock before the flashing operation and to take it again afterwards to
      ensure consistent state from the core code point of view. In this time,
      we take a reference to the device to prevent the device being freed
      while its being flashed.
      
      This provides protection for the device being flashed while at the same
      time not holding up any networking related functions which would
      otherwise be locked out due to RTNL being held.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4650b751
    • Dirk van der Merwe's avatar
      nfp: implement firmware flashing · 7a741565
      Dirk van der Merwe authored
      Firmware flashing takes around 60s (specified to not take more than
      70s). Prevent hogging the RTNL lock in this time and make use of the
      longer timeout for the NSP command. The timeout is set to 2.5 * 70
      seconds.
      
      We only allow flashing the firmware from reprs or PF netdevs. VFs do not
      have an app reference.
      Signed-off-by: default avatarDirk van der Merwe <dirk.vandermerwe@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7a741565
    • Dirk van der Merwe's avatar
      nfp: extend NSP infrastructure for configurable timeouts · 87a23801
      Dirk van der Merwe authored
      The firmware flashing NSP operation takes longer to execute than the
      current default timeout. We need a mechanism to set a longer timeout for
      some commands. This patch adds the infrastructure to this.
      
      The default timeout is still 30 seconds.
      Signed-off-by: default avatarDirk van der Merwe <dirk.vandermerwe@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      87a23801
    • David S. Miller's avatar
      Merge branch 'ipvlan-packet-scrub' · d31d38a0
      David S. Miller authored
      Mahesh Bandewar says:
      
      ====================
      ipvlan: packet scrub
      
      While crossing namespace boundary IPvlan aggressively scrubs packets.
      This is creating problems. First thing is that scrubbing changes the
      packet type in skb meta-data to PACKET_HOST. This causes erroneous
      packet delivery when dev_forward_skb() has already marked the packet
      type as OTHER_HOST.
      
      On the egress side scrubbing just before calling dev_queue_xmit()
      creates another set of problems. Scrubbing remove skb->sk so the
      prio update gets missed and more seriously, socket back-pressure
      fails making TSQ not function correctly.
      
      The first patch in the series just reverts the earlier change which
      was adding a mac-check, but that is unnecessary if packet_type that
      dev_forward_skb() has set is honored. The second path removes two of
      the scrubs which are causing problems described above.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d31d38a0
    • Mahesh Bandewar's avatar
      ipvlan: remove excessive packet scrubbing · c0d451c8
      Mahesh Bandewar authored
      IPvlan currently scrubs packets at every location where packets may be
      crossing namespace boundary. Though this is desirable, currently IPvlan
      does it more than necessary. e.g. packets that are going to take
      dev_forward_skb() path will get scrubbed so no point in scrubbing them
      before forwarding. Another side-effect of scrubbing is that pkt-type gets
      set to PACKET_HOST which overrides what was already been set by the
      earlier path making erroneous delivery of the packets.
      
      Also scrubbing packets just before calling dev_queue_xmit() has detrimental
      effects since packets lose skb->sk and because of that miss prio updates,
      incorrect socket back-pressure and would even break TSQ.
      
      Fixes: b93dd49c ('ipvlan: Scrub skb before crossing the namespace boundary')
      Signed-off-by: default avatarMahesh Bandewar <maheshb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c0d451c8
    • Mahesh Bandewar's avatar
      Revert "ipvlan: add L2 check for packets arriving via virtual devices" · 918150cb
      Mahesh Bandewar authored
      This reverts commit 92ff4264.
      
      Even though the check added is not that taxing, it's not really needed.
      First of all this will be per packet cost and second thing is that the
      eth_type_trans() already does this correctly. The excessive scrubbing
      in IPvlan was changing the pkt-type skb metadata of the packet which
      made it necessary to re-check the mac. The subsequent patch in this
      series removes the faulty packet-scrub.
      Signed-off-by: default avatarMahesh Bandewar <maheshb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      918150cb
    • David S. Miller's avatar
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next · 8ce38aeb
      David S. Miller authored
      Steffen Klassert says:
      
      ====================
      pull request (net-next): ipsec-next 2017-12-15
      
      1) Currently we can add or update socket policies, but
         not clear them. Support clearing of socket policies
         too. From Lorenzo Colitti.
      
      2) Add documentation for the xfrm device offload api.
         From Shannon Nelson.
      
      3) Fix IPsec extended sequence numbers (ESN) for
         IPsec offloading. From Yossef Efraim.
      
      4) xfrm_dev_state_add function returns success even for
         unsupported options, fix this to fail in such cases.
         From Yossef Efraim.
      
      5) Remove a redundant xfrm_state assignment.
         From Aviv Heller.
      
      Please pull or let me know if there are problems.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8ce38aeb
    • Florian Fainelli's avatar
      net: dsa: bcm_sf2: Update compatible string for 7278B0 · 3b07d788
      Florian Fainelli authored
      Update the compatible string and Device Tree binding document for
      7278B0.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3b07d788
    • David S. Miller's avatar
      Merge branch 'hnx3-vf' · 020929d6
      David S. Miller authored
      Salil Mehta says:
      
      ====================
      Hisilicon Network Subsystem 3 VF Ethernet Driver
      
      This patch-set contains the support of the HNS3 (Hisilicon Network Subsystem 3)
      Virtual Function Ethernet driver for hip08 family of SoCs. The Physical Function
      driver is already part of the Linux mainline.
      
      This VF driver has its Hardware Compatibility Layer and has commom/unified ENET
      layer/client/ethtool code with the PF driver. It also has support of mailbox to
      communicate with the HNS3 PF driver. The basic architecture of VF driver is
      derivative of the PF driver. Just like PF driver, this driver is also PCI
      Express based.
      
      This driver is the ongoing development work and HNS3 VF Ethernet driver would be
      incrementally enhanced with more new features.
      
      High Level Architecture:
      
                           [ Ethtool ]
      	                 |
                       [ Ethernet Client ] ... [ RoCE Client ]
                               |                     |
                         [ HNAE Device ]             |________
                               |                     |       |
          ---------------------------------------------      |
                                                             |
           [ HNAE3 Framework (Register/unregister) ]         |
                                                             |
          ---------------------------------------------      |
                               |                             |
                       [ VF HCLGE Layer ]                    |
                        |             |                      |
                        |             |                      |
                        |             |                      |
                        |     [ VF Mailbox (To PF via IMP) ] |
                        |             |                      |
                   [ IMP command Interface ]  [ IMP command Interface ]
                              |                              |
                              |                              |
                 (A B O V E  R U N S  O N  G U E S T  S Y S T E M)
          -------------------------------------------------------------
                    Q E M U / V F I O / K V M (on Host System)
          -------------------------------------------------------------
                  HIP08  H A R D W A R E (limited to VF by SMMU)
      
         [ IMP/Mgmt Processor (hardware common to system/cmd based) ]
      
                      Fig 1.   HNS3 Virtual Function Driver
      
          	[ dcbnl ]  [ Ethtool ]
                  |          |
         	[  Ethernet Client  ]  [ ODP/UIO Client ] . . .[ RoCE Client ]
                    |_____________________|                 |
                               |                   _________|
                         [ HNAE Device ]           |        |
                               |                   |        |
          ---------------------------------------------     |
                                                            |
           [ HNAE3 Framework (Register/unregister) ]        |
                                                            |
          ---------------------------------------------     |
                               |                            |
                        [ HCLGE Layer ]                     |
               ________________|_________________           |
              |                |                 |          |
           [ DCB ]             |                 |          |
              |                |                 |          |
        [ Scheduler/Shaper ] [ MDIO ]      [ PF Mailbox ]   |
              |                |                 |          |
              |________________|_________________|          |
                               |                            |
                   [ IMP command Interface ]     [ IMP command Interface ]
          ----------------------------------------------------------------
                    HIP08  H A R D W A R E
      
        [ IMP/Mgmt Processor (hardware common to system/cmd based) ]
      
                     Fig 2.    Existing HNS3 PF Driver (added with mailbox)
      
      Change Log Summary:
      Patch V4: Addressed SPDX related comment by Philippe Ombredanne
      Patch V3: Addressed SPDX change requested by Philippe Ombredanne
      Patch V2: 1. Addressed some comments by David Miller.
      	  2. Addressed some internal comments on various patches
      Patch V1: Initial Submit
      ====================
      Acked-by: default avatarPhilippe Ombredanne <pombredanne@nexb.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      020929d6
    • Salil Mehta's avatar
      net: hns3: Add mailbox interrupt handling to PF driver · c1a81619
      Salil Mehta authored
      All PF mailbox events are conveyed through a common interrupt
      (vector 0). This interrupt vector is shared by reset and mailbox.
      
      This patch adds the handling of mailbox interrupt event and its
      deferred processing in context to a separate mailbox task.
      Signed-off-by: default avatarSalil Mehta <salil.mehta@huawei.com>
      Signed-off-by: default avatarlipeng <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c1a81619
    • Salil Mehta's avatar
      net: hns3: Change PF to add ring-vect binding & resetQ to mailbox · 84e095d6
      Salil Mehta authored
      This patch is required to support ring-vector binding and reset
      of TQPs requested by the VF driver to the PF driver. Mailbox
      handler is added with corresponding VF commands/messages to
      handle the request.
      Signed-off-by: default avatarSalil Mehta <salil.mehta@huawei.com>
      Signed-off-by: default avatarlipeng <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      84e095d6
    • Salil Mehta's avatar
      net: hns3: Add mailbox support to PF driver · dde1a86e
      Salil Mehta authored
      Command queue provides the provision of Mailbox command which
      can be used for communication between PF and VF. PF handles
      messages from various VFs for fetching various information like,
      queue, vlan, link status related etc. It also handles the request
      from various VFs to perform certain privileged operations.
      
      This patch adds the support of a message handler for handling
      such various command requests from VF.
      Signed-off-by: default avatarSalil Mehta <salil.mehta@huawei.com>
      Signed-off-by: default avatarlipeng <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dde1a86e
    • Salil Mehta's avatar
      net: hns3: Unified HNS3 {VF|PF} Ethernet Driver for hip08 SoC · 424eb834
      Salil Mehta authored
      Most of the NAPI handling interface, skb buffer management,
      management of the RX/TX descriptors, ethool interface etc.
      has quite a bit of code which is common to VF and PF driver.
      
      This patch makes the exisitng PF's HNS3 ENET driver as the
      common ENET driver for both Virtual & Physical Function. This
      will help in reduction of redundancy and better management of
      code.
      Signed-off-by: default avatarSalil Mehta <salil.mehta@huawei.com>
      Signed-off-by: default avatarlipeng <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      424eb834
    • Salil Mehta's avatar
      net: hns3: Add HNS3 VF driver to kernel build framework · e963cb78
      Salil Mehta authored
      This patch introduces the new Makefiles and updates existing
      Makefiles required to build the HNS3 Virtual Function driver.
      This also updates the Kconfig for introduction of new menuconfig
      entries related to VF driver.
      Signed-off-by: default avatarSalil Mehta <salil.mehta@huawei.com>
      Signed-off-by: default avatarlipeng <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e963cb78
    • Salil Mehta's avatar
      net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support · e2cb1dec
      Salil Mehta authored
      This patch adds the support of hardware compatibiltiy layer to the
      HNS3 VF Driver. This layer implements various {set|get} operations
      over MAC address for a virtual port, RSS related configuration,
      fetches the link status info from PF, does various VLAN related
      configuration over the virtual port, queries the statistics from
      the hardware etc.
      
      This layer can directly interact with hardware through the
      IMP(Integrated Mangement Processor) interface or can use mailbox
      to interact with the PF driver.
      Signed-off-by: default avatarSalil Mehta <salil.mehta@huawei.com>
      Signed-off-by: default avatarlipeng <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e2cb1dec
    • Salil Mehta's avatar
      net: hns3: Add mailbox support to VF driver · b11a0bb2
      Salil Mehta authored
      This patch adds the support of the mailbox to the VF driver. The
      mailbox shall be used as an interface to communicate with the
      PF driver for various purposes like {set|get} MAC related
      operations, reset, link status etc. The mailbox supports both
      synchronous and asynchronous command send to PF driver.
      Signed-off-by: default avatarSalil Mehta <salil.mehta@huawei.com>
      Signed-off-by: default avatarlipeng <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b11a0bb2
    • Salil Mehta's avatar
      net: hns3: Add HNS3 VF IMP(Integrated Management Proc) cmd interface · fedd0c15
      Salil Mehta authored
      This patch adds support of command interface for communication with
      the IMP(Integrated Management Processor) for HNS3 Virtual Function
      Driver.
      
      Each VF has support of CQP(Command Queue Pair) ring interface.
      Each CQP consis of send queue CSQ and receive queue CRQ.
      There are various commands a VF may support, like to query frimware
      version, TQP management, statistics, interrupt related, mailbox etc.
      
      This also contains code to initialize the command queue, manage the
      command queue descriptors and Rx/Tx protocol with the command processor
      in the form of various commands/results and acknowledgements.
      Signed-off-by: default avatarSalil Mehta <salil.mehta@huawei.com>
      Signed-off-by: default avatarlipeng <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fedd0c15
    • David S. Miller's avatar
      Merge branch 'dsa-MT7530-vlan' · be17bbec
      David S. Miller authored
      Sean Wang says:
      
      ====================
      add VLAN support to DSA MT7530
      
      Changes sicne v2:
      update to the latest code base from net-next and fix up all building
      errors with -Werror.
      
      Changes since v1:
      - fix up the typo
      - prefer ordering declarations longest to shortest
      - update that vlan_prepare callback should not change any state
      - use lower case letter for function naming
      
      The patchset extends DSA MT7530 to VLAN support through filling required
      callbacks in patch 1 and merging the special tag with VLAN tag in patch 2
      for allowing that the hardware can handle these packets with VID from the
      CPU port.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      be17bbec
    • Sean Wang's avatar
      net: dsa: mediatek: update MAINTAINERS entry with MediaTek switch driver · 423d1290
      Sean Wang authored
      I work for MediaTek and maintain SoC targeting to home gateway and
      also will keep extending and testing the function from MediaTek
      switch.
      Signed-off-by: default avatarSean Wang <sean.wang@mediatek.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      423d1290
    • Sean Wang's avatar
      net: dsa: mediatek: combine MediaTek tag with VLAN tag · f0af3431
      Sean Wang authored
      In order to let MT7530 switch can recognize well those egress packets
      having both special tag and VLAN tag, the information about the special
      tag should be carried on the existing VLAN tag. On the other hand, it's
      unnecessary for extra handling for ingress packets when VLAN tag is
      present since it is able to put the VLAN tag after the special tag and
      then follow the existing way to parse.
      Signed-off-by: default avatarSean Wang <sean.wang@mediatek.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f0af3431
    • Sean Wang's avatar
      net: dsa: mediatek: add VLAN support for MT7530 · 83163f7d
      Sean Wang authored
      MT7530 can treat each port as either VLAN-unaware port or VLAN-aware port
      through the implementation of port matrix mode or port security mode on
      the ingress port, respectively. On one hand, Each port has been acting as
      the VLAN-unaware one whenever the device is created in the initial or
      certain port joins or leaves into/from the bridge at the runtime. On the
      other hand, the patch just filling the required callbacks for VLAN
      operations is achieved via extending the port to be into port security
      mode when the port is configured as VLAN-aware port. Which mode can make
      the port be able to recognize VID from incoming packets and look up VLAN
      table to validate and judge which port it should be going to. And the
      range for VID from 1 to 4094 is valid for the hardware.
      Signed-off-by: default avatarSean Wang <sean.wang@mediatek.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      83163f7d
  2. 13 Dec, 2017 16 commits