1. 20 Dec, 2021 9 commits
  2. 19 Dec, 2021 14 commits
  3. 18 Dec, 2021 9 commits
  4. 17 Dec, 2021 8 commits
    • Brett Creeley's avatar
      iavf: Restrict maximum VLAN filters for VIRTCHNL_VF_OFFLOAD_VLAN_V2 · 92fc5085
      Brett Creeley authored
      For VIRTCHNL_VF_OFFLOAD_VLAN, PF's would limit the number of VLAN
      filters a VF was allowed to add. However, by the time the opcode failed,
      the VLAN netdev had already been added. VIRTCHNL_VF_OFFLOAD_VLAN_V2
      added the ability for a PF to tell the VF how many VLAN filters it's
      allowed to add. Make changes to support that functionality.
      Signed-off-by: default avatarBrett Creeley <brett.creeley@intel.com>
      Tested-by: default avatarKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      92fc5085
    • Brett Creeley's avatar
      iavf: Add support for VIRTCHNL_VF_OFFLOAD_VLAN_V2 offload enable/disable · 8afadd1c
      Brett Creeley authored
      The new VIRTCHNL_VF_OFFLOAD_VLAN_V2 capability added support that allows
      the VF to support 802.1Q and 802.1ad VLAN insertion and stripping if
      successfully negotiated via VIRTCHNL_OP_GET_OFFLOAD_VLAN_V2_CAPS.
      Multiple changes were needed to support this new functionality.
      
      1. Added new aq_required flags to support any kind of VLAN stripping and
         insertion offload requests via virtchnl.
      
      2. Added the new method iavf_set_vlan_offload_features() that's
         used during VF initialization, VF reset, and iavf_set_features() to
         set the aq_required bits based on the current VLAN offload
         configuration of the VF's netdev.
      
      3. Added virtchnl handling for VIRTCHNL_OP_ENABLE_STRIPPING_V2,
         VIRTCHNL_OP_DISABLE_STRIPPING_V2, VIRTCHNL_OP_ENABLE_INSERTION_V2,
         and VIRTCHNL_OP_ENABLE_INSERTION_V2.
      Signed-off-by: default avatarBrett Creeley <brett.creeley@intel.com>
      Tested-by: default avatarKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      8afadd1c
    • Brett Creeley's avatar
      iavf: Add support for VIRTCHNL_VF_OFFLOAD_VLAN_V2 hotpath · ccd219d2
      Brett Creeley authored
      The new VIRTCHNL_VF_OFFLOAD_VLAN_V2 capability added support that allows
      the PF to set the location of the Tx and Rx VLAN tag for insertion and
      stripping offloads. In order to support this functionality a few changes
      are needed.
      
      1. Add a new method to cache the VLAN tag location based on negotiated
         capabilities for the Tx and Rx ring flags. This needs to be called in
         the initialization and reset paths.
      
      2. Refactor the transmit hotpath to account for the new Tx ring flags.
         When IAVF_TXR_FLAGS_VLAN_LOC_L2TAG2 is set, then the driver needs to
         insert the VLAN tag in the L2TAG2 field of the transmit descriptor.
         When the IAVF_TXRX_FLAGS_VLAN_LOC_L2TAG1 is set, then the driver needs
         to use the l2tag1 field of the data descriptor (same behavior as
         before).
      
      3. Refactor the iavf_tx_prepare_vlan_flags() function to simplify
         transmit hardware VLAN offload functionality by only depending on the
         skb_vlan_tag_present() function. This can be done because the OS
         won't request transmit offload for a VLAN unless the driver told the
         OS it's supported and enabled.
      
      4. Refactor the receive hotpath to account for the new Rx ring flags and
         VLAN ethertypes. This requires checking the Rx ring flags and
         descriptor status bits to determine the location of the VLAN tag.
         Also, since only a single ethertype can be supported at a time, check
         the enabled netdev features before specifying a VLAN ethertype in
         __vlan_hwaccel_put_tag().
      Signed-off-by: default avatarBrett Creeley <brett.creeley@intel.com>
      Tested-by: default avatarKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      ccd219d2
    • Brett Creeley's avatar
      iavf: Add support VIRTCHNL_VF_OFFLOAD_VLAN_V2 during netdev config · 48ccc43e
      Brett Creeley authored
      Based on VIRTCHNL_VF_OFFLOAD_VLAN_V2, the VF can now support more VLAN
      capabilities (i.e. 802.1AD offloads and filtering). In order to
      communicate these capabilities to the netdev layer, the VF needs to
      parse its VLAN capabilities based on whether it was able to negotiation
      VIRTCHNL_VF_OFFLOAD_VLAN or VIRTCHNL_VF_OFFLOAD_VLAN_V2 or neither of
      these.
      
      In order to support this, add the following functionality:
      
      iavf_get_netdev_vlan_hw_features() - This is used to determine the VLAN
      features that the underlying hardware supports and that can be toggled
      off/on based on the negotiated capabiltiies. For example, if
      VIRTCHNL_VF_OFFLOAD_VLAN_V2 was negotiated, then any capability marked
      with VIRTCHNL_VLAN_TOGGLE can be toggled on/off by the VF. If
      VIRTCHNL_VF_OFFLOAD_VLAN was negotiated, then only VLAN insertion and/or
      stripping can be toggled on/off.
      
      iavf_get_netdev_vlan_features() - This is used to determine the VLAN
      features that the underlying hardware supports and that should be
      enabled by default. For example, if VIRTHCNL_VF_OFFLOAD_VLAN_V2 was
      negotiated, then any supported capability that has its ethertype_init
      filed set should be enabled by default. If VIRTCHNL_VF_OFFLOAD_VLAN was
      negotiated, then filtering, stripping, and insertion should be enabled
      by default.
      
      Also, refactor iavf_fix_features() to take into account the new
      capabilities. To do this, query all the supported features (enabled by
      default and toggleable) and make sure the requested change is supported.
      If VIRTCHNL_VF_OFFLOAD_VLAN_V2 is successfully negotiated, there is no
      need to check VIRTCHNL_VLAN_TOGGLE here because the driver already told
      the netdev layer which features can be toggled via netdev->hw_features
      during iavf_process_config(), so only those features will be requested
      to change.
      Signed-off-by: default avatarBrett Creeley <brett.creeley@intel.com>
      Tested-by: default avatarKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      48ccc43e
    • Brett Creeley's avatar
      iavf: Add support for VIRTCHNL_VF_OFFLOAD_VLAN_V2 negotiation · 209f2f9c
      Brett Creeley authored
      In order to support the new VIRTCHNL_VF_OFFLOAD_VLAN_V2 capability the
      VF driver needs to rework it's initialization state machine and reset
      flow. This has to be done because successful negotiation of
      VIRTCHNL_VF_OFFLOAD_VLAN_V2 requires the VF driver to perform a second
      capability request via VIRTCHNL_OP_GET_OFFLOAD_VLAN_V2_CAPS before
      configuring the adapter and its netdev.
      
      Add the VIRTCHNL_VF_OFFLOAD_VLAN_V2 bit when sending the
      VIRTHCNL_OP_GET_VF_RESOURECES message. The underlying PF will either
      support VIRTCHNL_VF_OFFLOAD_VLAN or VIRTCHNL_VF_OFFLOAD_VLAN_V2 or
      neither. Both of these offloads should never be supported together.
      
      Based on this, add 2 new states to the initialization state machine:
      
      __IAVF_INIT_GET_OFFLOAD_VLAN_V2_CAPS
      __IAVF_INIT_CONFIG_ADAPTER
      
      The __IAVF_INIT_GET_OFFLOAD_VLAN_V2_CAPS state is used to request/store
      the new VLAN capabilities if and only if VIRTCHNL_VLAN_OFFLOAD_VLAN_V2
      was successfully negotiated in the __IAVF_INIT_GET_RESOURCES state.
      
      The __IAVF_INIT_CONFIG_ADAPTER state is used to configure the
      adapter/netdev after the resource requests have finished. The VF will
      move into this state regardless of whether it successfully negotiated
      VIRTCHNL_VF_OFFLOAD_VLAN or VIRTCHNL_VF_OFFLOAD_VLAN_V2.
      
      Also, add a the new flag IAVF_FLAG_AQ_GET_OFFLOAD_VLAN_V2_CAPS and set
      it during VF reset. If VIRTCHNL_VF_OFFLOAD_VLAN_V2 was successfully
      negotiated then the VF will request its VLAN capabilities via
      VIRTCHNL_OP_GET_OFFLOAD_VLAN_V2_CAPS during the reset. This is needed
      because the PF may change/modify the VF's configuration during VF reset
      (i.e. modifying the VF's port VLAN configuration).
      
      This also, required the VF to call netdev_update_features() since its
      VLAN features may change during VF reset. Make sure to call this under
      rtnl_lock().
      Signed-off-by: default avatarBrett Creeley <brett.creeley@intel.com>
      Tested-by: default avatarKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      209f2f9c
    • Brett Creeley's avatar
      virtchnl: Add support for new VLAN capabilities · bd0b536d
      Brett Creeley authored
      Currently VIRTCHNL only allows for VLAN filtering and offloads to happen
      on a single 802.1Q VLAN. Add support to filter and offload on inner,
      outer, and/or inner + outer VLANs.
      
      This is done by introducing the new capability
      VIRTCHNL_VF_OFFLOAD_VLAN_V2. The flow to negotiate this new capability
      is shown below.
      
      1. VF - sets the VIRTCHNL_VF_OFFLOAD_VLAN_V2 bit in the
         virtchnl_vf_resource.vf_caps_flags during the
         VIRTCHNL_OP_GET_VF_RESOURCES request message. The VF should also set
         the VIRTCHNL_VF_OFFLOAD_VLAN bit in case the PF driver doesn't support
         the new capability.
      
      2. PF - sets the VLAN capability bit it supports in the
         VIRTCHNL_OP_GET_VF_RESOURCES response message. This will either be
         VIRTCHNL_VF_OFFLOAD_VLAN_V2, VIRTCHNL_VF_OFFLOAD_VLAN, or none.
      
      3. VF - If the VIRTCHNL_VF_OFFLOAD_VLAN_V2 capability was ACK'd by the
         PF, then the VF needs to request the VLAN capabilities of the
         PF/Device by issuing a VIRTCHNL_OP_GET_OFFLOAD_VLAN_V2_CAPS request.
         If the VIRTCHNL_VF_OFFLOAD_VLAN capability was ACK'd then the VF
         knows only single 802.1Q VLAN filtering/offloads are supported. If no
         VLAN capability is ACK'd then the PF/Device doesn't support hardware
         VLAN filtering/offloads for this VF.
      
      4. PF - Populates the virtchnl_vlan_caps structure based on what it
         allows/supports for that VF and sends that response via
         VIRTCHNL_OP_GET_OFFLOAD_VLAN_V2_CAPS.
      
      After VIRTCHNL_OP_GET_OFFLOAD_VLAN_V2_CAPS is successfully negotiated
      the VF driver needs to interpret the capabilities supported by the
      underlying PF/Device. The VF will be allowed to filter/offload the
      inner 802.1Q, outer (various ethertype), inner 802.1Q + outer
      (various ethertypes), or none based on which fields are set.
      
      The VF will also need to interpret where the VLAN tag should be inserted
      and/or stripped based on the negotiated capabilities.
      Signed-off-by: default avatarBrett Creeley <brett.creeley@intel.com>
      Tested-by: default avatarKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      bd0b536d
    • Jakub Kicinski's avatar
      Merge tag 'wireless-drivers-next-2021-12-17' of... · f75c1d55
      Jakub Kicinski authored
      Merge tag 'wireless-drivers-next-2021-12-17' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
      
      Kalle Valo says:
      
      ====================
      wireless-drivers-next patches for v5.17
      
      Second set of patches for v5.17, planning to do at least one more.
      Smaller new features, nothing special this time.
      
      Major changes:
      
      rtw88
       * debugfs file to fix tx rate
      
      iwlwifi
       * support SAR GEO Offset Mapping (SGOM) via BIOS
       * support firmware API version 68
       * add some new device IDs
      
      ath11k
       * support PCI devices with 1 MSI vector
       * WCN6855 hw2.1 support
       * 11d scan offload support
       * full monitor mode, only supported on QCN9074
       * scan MAC address randomization support
       * reserved host DDR addresses from DT for PCI devices support
      
      ath9k
       * switch to rate table based lookup
      
      ath
       * extend South Korea regulatory domain support
      
      wcn36xx
       * beacon filter support
      
      * tag 'wireless-drivers-next-2021-12-17' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next: (129 commits)
        wcn36xx: Implement beacon filtering
        wcn36xx: Fix physical location of beacon filter comment
        wcn36xx: Fix beacon filter structure definitions
        ath11k: Use reserved host DDR addresses from DT for PCI devices
        dt: bindings: add new DT entry for ath11k PCI device support
        wilc1000: Improve WILC TX performance when power_save is off
        wl1251: specify max. IE length
        rsi: fix array out of bound
        wilc1000: Rename workqueue from "WILC_wq" to "NETDEV-wq"
        wilc1000: Rename tx task from "K_TXQ_TASK" to NETDEV-tx
        wilc1000: Rename irq handler from "WILC_IRQ" to netdev name
        wilc1000: Rename SPI driver from "WILC_SPI" to "wilc1000_spi"
        wilc1000: Fix spurious "FW not responding" error
        wilc1000: Remove misleading USE_SPI_DMA macro
        wilc1000: Fix missing newline in error message
        wilc1000: Fix copy-and-paste typo in wilc_set_mac_address
        rtw89: coex: Update COEX to 5.5.8
        rtw89: coex: Cancel PS leaving while C2H comes
        rtw89: coex: Update BT counters while receiving report
        rtw89: coex: Define LPS state for BTC using
        ...
      ====================
      
      Link: https://lore.kernel.org/r/20211217130952.34887C36AE9@smtp.kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f75c1d55
    • Changcheng Deng's avatar
      net: dsa: microchip: remove unneeded variable · 86df8be6
      Changcheng Deng authored
      Remove unneeded variable used to store return value.
      Reported-by: default avatarZeal Robot <zealci@zte.com.cn>
      Signed-off-by: default avatarChangcheng Deng <deng.changcheng@zte.com.cn>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      86df8be6