1. 01 4月, 2021 3 次提交
  2. 23 3月, 2021 2 次提交
  3. 23 2月, 2021 1 次提交
  4. 09 2月, 2021 3 次提交
  5. 06 2月, 2021 1 次提交
  6. 27 1月, 2021 1 次提交
    • B
      ice: Fix MSI-X vector fallback logic · f3fe97f6
      Brett Creeley 提交于
      The current MSI-X enablement logic tries to enable best-case MSI-X
      vectors and if that fails we only support a bare-minimum set. This
      includes a single MSI-X for 1 Tx and 1 Rx queue and a single MSI-X
      for the OICR interrupt. Unfortunately, the driver fails to load when we
      don't get as many MSI-X as requested for a couple reasons.
      
      First, the code to allocate MSI-X in the driver tries to allocate
      num_online_cpus() MSI-X for LAN traffic without caring about the number
      of MSI-X actually enabled/requested from the kernel for LAN traffic.
      So, when calling ice_get_res() for the PF VSI, it returns failure
      because the number of available vectors is less than requested. Fix
      this by not allowing the PF VSI to allocation  more than
      pf->num_lan_msix MSI-X vectors and pf->num_lan_msix Rx/Tx queues.
      Limiting the number of queues is done because we don't want more than
      1 Tx/Rx queue per interrupt due to performance conerns.
      
      Second, the driver assigns pf->num_lan_msix = 2, to account for LAN
      traffic and the OICR. However, pf->num_lan_msix is only meant for LAN
      MSI-X. This is causing a failure when the PF VSI tries to
      allocate/reserve the minimum pf->num_lan_msix because the OICR MSI-X has
      already been reserved, so there may not be enough MSI-X vectors left.
      Fix this by setting pf->num_lan_msix = 1 for the failure case. Then the
      ICE_MIN_MSIX accounts for the LAN MSI-X and the OICR MSI-X needed for
      the failure case.
      
      Update the related defines used in ice_ena_msix_range() to align with
      the above behavior and remove the unused RDMA defines because RDMA is
      currently not supported. Also, remove the now incorrect comment.
      
      Fixes: 152b978a ("ice: Rework ice_ena_msix_range")
      Signed-off-by: NBrett Creeley <brett.creeley@intel.com>
      Tested-by: NTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      f3fe97f6
  7. 10 12月, 2020 1 次提交
  8. 10 10月, 2020 1 次提交
    • J
      ice: refactor devlink_port to be per-VSI · 48d40025
      Jacob Keller 提交于
      Currently, the devlink_port structure is stored within the ice_pf. This
      made sense because we create a single devlink_port for each PF. This
      setup does not mesh with the abstractions in the driver very well, and
      led to a flow where we accidentally call devlink_port_unregister twice
      during error cleanup.
      
      In particular, if devlink_port_register or devlink_port_unregister are
      called twice, this leads to a kernel panic. This appears to occur during
      some possible flows while cleaning up from a failure during driver
      probe.
      
      If register_netdev fails, then we will call devlink_port_unregister in
      ice_cfg_netdev as it cleans up. Later, we again call
      devlink_port_unregister since we assume that we must cleanup the port
      that is associated with the PF structure.
      
      This occurs because we cleanup the devlink_port for the main PF even
      though it was not allocated. We allocated the port within a per-VSI
      function for managing the main netdev, but did not release the port when
      cleaning up that VSI, the allocation and destruction are not aligned.
      
      Instead of attempting to manage the devlink_port as part of the PF
      structure, manage it as part of the PF VSI. Doing this has advantages,
      as we can match the de-allocation of the devlink_port with the
      unregister_netdev associated with the main PF VSI.
      
      Moving the port to the VSI is preferable as it paves the way for
      handling devlink ports allocated for other purposes such as SR-IOV VFs.
      
      Since we're changing up how we allocate the devlink_port, also change
      the indexing. Originally, we indexed the port using the PF id number.
      This came from an old goal of sharing a devlink for each physical
      function. Managing devlink instances across multiple function drivers is
      not workable. Instead, lets set the port number to the logical port
      number returned by firmware and set the index using the VSI index
      (sometimes referred to as VSI handle).
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      48d40025
  9. 26 9月, 2020 1 次提交
    • J
      intel-ethernet: clean up W=1 warnings in kdoc · b50f7bca
      Jesse Brandeburg 提交于
      This takes care of all of the trivial W=1 fixes in the Intel
      Ethernet drivers, which allows developers and maintainers to
      build more of the networking tree with more complete warning
      checks.
      
      There are three classes of kdoc warnings fixed:
       - cannot understand function prototype: 'x'
       - Excess function parameter 'x' description in 'y'
       - Function parameter or member 'x' not described in 'y'
      
      All of the changes were trivial comment updates on
      function headers.
      
      Inspired by Lee Jones' series of wireless work to do the same.
      Compile tested only, and passes simple test of
      $ git ls-files *.[ch] | egrep drivers/net/ethernet/intel | \
        xargs scripts/kernel-doc -none
      Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b50f7bca
  10. 01 9月, 2020 1 次提交
  11. 01 8月, 2020 1 次提交
    • J
      ice: add useful statistics · a8fffd7a
      Jesse Brandeburg 提交于
      Display and count some useful hot-path statistics. The usefulness is as
      follows:
      
      - tx_restart: use to determine if the transmit ring size is too small or
        if the transmit interrupt rate is too low.
      - rx_gro_dropped: use to count drops from GRO layer, which previously were
        completely uncounted when occurring.
      - tx_busy: use to determine when the driver is miscounting number of
        descriptors needed for an skb.
      - tx_timeout: as our other drivers, count the number of times we've reset
        due to timeout because the kernel only prints a warning once per netdev.
      
      Several of these were already counted but not displayed.
      Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      a8fffd7a
  12. 29 7月, 2020 1 次提交
    • J
      ice: implement device flash update via devlink · d69ea414
      Jacob Keller 提交于
      Use the newly added pldmfw library to implement device flash update for
      the Intel ice networking device driver. This support uses the devlink
      flash update interface.
      
      The main parts of the flash include the Option ROM, the netlist module,
      and the main NVM data. The PLDM firmware file contains modules for each
      of these components.
      
      Using the pldmfw library, the provided firmware file will be scanned for
      the three major components, "fw.undi" for the Option ROM, "fw.mgmt" for
      the main NVM module containing the primary device firmware, and
      "fw.netlist" containing the netlist module.
      
      The flash is separated into two banks, the active bank containing the
      running firmware, and the inactive bank which we use for update. Each
      module is updated in a staged process. First, the inactive bank is
      erased, preparing the device for update. Second, the contents of the
      component are copied to the inactive portion of the flash. After all
      components are updated, the driver signals the device to switch the
      active bank during the next EMP reset (which would usually occur during
      the next reboot).
      
      Although the firmware AdminQ interface does report an immediate status
      for each command, the NVM erase and NVM write commands receive status
      asynchronously. The driver must not continue writing until previous
      erase and write commands have finished. The real status of the NVM
      commands is returned over the receive AdminQ. Implement a simple
      interface that uses a wait queue so that the main update thread can
      sleep until the completion status is reported by firmware. For erasing
      the inactive banks, this can take quite a while in practice.
      
      To help visualize the process to the devlink application and other
      applications based on the devlink netlink interface, status is reported
      via the devlink_flash_update_status_notify. While we do report status
      after each 4k block when writing, there is no real status we can report
      during erasing. We simply must wait for the complete module erasure to
      finish.
      
      With this implementation, basic flash update for the ice hardware is
      supported.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d69ea414
  13. 24 7月, 2020 4 次提交
  14. 02 7月, 2020 1 次提交
  15. 26 6月, 2020 1 次提交
    • J
      net/intel: remove driver versions from Intel drivers · 34a2a3b8
      Jeff Kirsher 提交于
      As with other networking drivers, remove the unnecessary driver version
      from the Intel drivers. The ethtool driver information and module version
      will then report the kernel version instead.
      
      For ixgbe, i40e and ice drivers, the driver passes the driver version to
      the firmware to confirm that we are up and running.  So we now pass the
      value of UTS_RELEASE to the firmware.  This adminq call is required per
      the HAS document.  The Device then sends an indication to the BMC that the
      PF driver is present. This is done using Host NC Driver Status Indication
      in NC-SI Get Link command or via the Host Network Controller Driver Status
      Change AEN.
      
      What the BMC may do with this information is implementation-dependent, but
      this is a standard NC-SI 1.1 command we honor per the HAS.
      
      CC: Bruce Allan <bruce.w.allan@intel.com>
      CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
      CC: Alek Loktionov <aleksandr.loktionov@intel.com>
      CC: Kevin Liedtke <kevin.d.liedtke@intel.com>
      CC: Aaron Rowden <aaron.f.rowden@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Co-developed-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      34a2a3b8
  16. 23 5月, 2020 5 次提交
  17. 22 5月, 2020 5 次提交
  18. 27 3月, 2020 1 次提交
  19. 21 3月, 2020 1 次提交
    • J
      ice: enable initial devlink support · 1adf7ead
      Jacob Keller 提交于
      Begin implementing support for the devlink interface with the ice
      driver.
      
      The pf structure is currently memory managed through devres, via
      a devm_alloc. To mimic this behavior, after allocating the devlink
      pointer, use devm_add_action to add a teardown action for releasing the
      devlink memory on exit.
      
      The ice hardware is a multi-function PCIe device. Thus, each physical
      function will get its own devlink instance. This means that each
      function will be treated independently, with its own parameters and
      configuration. This is done because the ice driver loads a separate
      instance for each function.
      
      Due to this, the implementation does not enable devlink to manage
      device-wide resources or configuration, as each physical function will
      be treated independently. This is done for simplicity, as managing
      a devlink instance across multiple driver instances would significantly
      increase the complexity for minimal gain.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      1adf7ead
  20. 11 3月, 2020 4 次提交
  21. 20 2月, 2020 1 次提交