1. 11 6月, 2021 2 次提交
    • J
      ice: add support for set/get of driver-stored firmware parameters · 7f9ab54d
      Jacob Keller 提交于
      Depending on the device configuration, the ice hardware may share the
      PTP hardware clock timer between multiple PFs. Each PF is informed by
      firmware during initialization of the PTP timer association.
      
      When bringing up PTP, only the PFs which own the timer shall allocate
      a PTP hardware clock. Other PFs associated with that timer must report
      the correct PTP clock index in order to allow userspace software the
      ability to know which ports are connected to the same clock.
      
      To support this, the firmware has driver shared parameters. These
      parameters enable one PF to write the clock index into firmware, and
      have other PFs read the associated value out. This enables the driver to
      have only a single PF allocate and control the device timer registers,
      while other PFs associated with that timer can report the correct clock
      in the ETHTOOL_GET_TS_INFO report.
      
      Add support for the necessary admin queue commands to enable reading and
      writing of the driver shared parameters. This will be used in a future
      change to enable sharing the PTP clock index between PF drivers.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      7f9ab54d
    • J
      ice: add support for sideband messages · 8f5ee3c4
      Jacob Keller 提交于
      In order to support certain device features, including enabling the PTP
      hardware clock, the ice driver needs to control some registers on the
      device PHY.
      
      These registers are accessed by sending sideband messages. For some
      hardware, these messages must be sent over the device admin queue, while
      other hardware has a dedicated control queue for the sideband messages.
      
      Add the neighbor device message structure for sending a message to the
      neighboring device. Where supported, initialize the sideband control
      queue and handle cleanup.
      
      Add a wrapper function for sending sideband control queue messages that
      read or write a neighboring device register.
      
      Because some devices send sideband messages over the AdminQ, also
      increase the length of the admin queue to allow more messages to be
      queued up. This is important because the sideband messages add
      additional pressure on the AQ usage.
      
      This support will be used in following patches to enable support for
      CONFIG_1588_PTP_CLOCK.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      8f5ee3c4
  2. 29 5月, 2021 1 次提交
  3. 08 4月, 2021 2 次提交
  4. 01 4月, 2021 1 次提交
  5. 09 2月, 2021 1 次提交
    • D
      ice: implement new LLDP filter command · 34295a36
      Dave Ertman 提交于
      There is an issue with some NVMs where an already existent LLDP
      filter is blocking the creation of a filter to allow LLDP packets
      to be redirected to the default VSI for the interface.  This is
      blocking all LLDP functionality based in the kernel when the FW
      LLDP agent is disabled (e.g. software based DCBx).
      
      Implement the new AQ command to allow adding VSI destinations to
      existent filters on NVM versions that support the new command.
      
      The new lldp_fltr_ctrl AQ command supports Rx filters only, so the
      code flow for adding filters to disable Tx of control frames will
      remain intact.
      Signed-off-by: NDave Ertman <david.m.ertman@intel.com>
      Tested-by: NTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      34295a36
  6. 29 7月, 2020 3 次提交
    • D
      ice: Implement LFC workaround · 7d9c9b79
      Dave Ertman 提交于
      There is a bug where the LFC settings are not being preserved
      through a link event.  The registers in question are the ones
      that are touched (and restored) when a set_local_mib AQ command
      is performed.
      
      On a link-up event, make sure that a set_local_mib is being
      performed.
      
      Move the function ice_aq_set_lldp_mib() from the DCB specific
      ice_dcb.c to ice_common.c so that the driver always has access
      to this AQ command.
      Signed-off-by: NDave Ertman <david.m.ertman@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      7d9c9b79
    • 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
    • C
      ice: Add AdminQ commands for FW update · 544cd2ac
      Cudzilo, Szymon T 提交于
      Add structures, identifiers, and helper functions for several AdminQ
      commands related to performing a firmware update for the ice hardware.
      These will be used in future code for implementing the devlink
      .flash_update handler.
      Signed-off-by: NCudzilo, Szymon T <szymon.t.cudzilo@intel.com>
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      544cd2ac
  7. 24 7月, 2020 4 次提交
  8. 02 7月, 2020 2 次提交
  9. 28 5月, 2020 1 次提交
  10. 23 5月, 2020 1 次提交
  11. 21 3月, 2020 3 次提交
  12. 13 2月, 2020 1 次提交
  13. 26 1月, 2020 1 次提交
  14. 25 1月, 2020 1 次提交
  15. 09 11月, 2019 2 次提交
  16. 07 11月, 2019 2 次提交
  17. 13 9月, 2019 4 次提交
  18. 01 8月, 2019 2 次提交
    • J
      ice: separate out control queue lock creation · 5c91ecfd
      Jacob Keller 提交于
      The ice_init_all_ctrlq and ice_shutdown_all_ctrlq functions create and
      destroy the locks used to protect the send and receive process of each
      control queue.
      
      This is problematic, as the driver may use these functions to shutdown
      and re-initialize the control queues at run time. For example, it may do
      this in response to a device reset.
      
      If the driver failed to recover from a reset, it might leave the control
      queues offline. In this case, the locks will no longer be initialized.
      A later call to ice_sq_send_cmd will then attempt to acquire a lock that
      has been destroyed.
      
      It is incorrect behavior to access a lock that has been destroyed.
      
      Indeed, ice_aq_send_cmd already tries to avoid accessing an offline
      control queue, but the check occurs inside the lock.
      
      The root of the problem is that the locks are destroyed at run time.
      
      Modify ice_init_all_ctrlq and ice_shutdown_all_ctrlq such that they no
      longer create or destroy the locks.
      
      Introduce new functions, ice_create_all_ctrlq and ice_destroy_all_ctrlq.
      Call these functions in ice_init_hw and ice_deinit_hw.
      
      Now, the control queue locks will remain valid for the life of the
      driver, and will not be destroyed until the driver unloads.
      
      This also allows removing a duplicate check of the sq.count and
      rq.count values when shutting down the controlqs. The ice_shutdown_ctrlq
      function already checks this value under the lock. Previously
      commit dec64ff1 ("ice: use [sr]q.count when checking if queue is
      initialized") needed this check to happen outside the lock, because it
      prevented duplicate attempts at destroying the locks.
      
      The driver may now safely use ice_init_all_ctrlq and
      ice_shutdown_all_ctrlq while handling reset events, without causing the
      locks to be invalid.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      5c91ecfd
    • J
      ice: track hardware stat registers past rollover · 36517fd3
      Jacob Keller 提交于
      Currently, ice_stat_update32 and ice_stat_update40 will limit the
      value of the software statistic to 32 or 40 bits wide, depending on
      which register is being read.
      
      This means that if a driver is running for a long time, the displayed
      software register values will roll over to zero at 40 bits or 32 bits.
      
      This occurs because the functions directly assign the difference between
      the previous value and current value of the hardware statistic.
      
      Instead, add this value to the current software statistic, and then
      update the previous value.
      
      In this way, each time ice_stat_update40 or ice_stat_update32 are
      called, they will increment the software tracking value by the
      difference of the hardware register from its last read. The software
      tracking value will correctly count up until it overflows a u64.
      
      The only requirement is that the ice_stat_update functions be called at
      least once each time the hardware register overflows.
      
      While we're fixing ice_stat_update40, modify it to use rd64 instead of
      two calls to rd32. Additionally, drop the now unnecessary hireg
      function parameter.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      36517fd3
  19. 30 5月, 2019 1 次提交
  20. 29 5月, 2019 1 次提交
  21. 02 5月, 2019 1 次提交
  22. 18 4月, 2019 1 次提交
    • A
      ice: Add code for DCB initialization part 3/4 · 7b9ffc76
      Anirudh Venkataramanan 提交于
      This patch adds a new function ice_pf_dcb_cfg (and related helpers)
      which applies the DCB configuration obtained from the firmware. As
      part of this, VSIs/netdevs are updated with traffic class information.
      
      This patch requires a bit of a refactor of existing code.
      
      1. For a MIB change event, the associated VSI is closed and brought up
         again. The gap between closing and opening the VSI can cause a race
         condition. Fix this by grabbing the rtnl_lock prior to closing the
         VSI and then only free it after re-opening the VSI during a MIB
         change event.
      
      2. ice_sched_query_elem is used in ice_sched.c and with this patch, in
         ice_dcb.c as well. However, ice_dcb.c is not built when CONFIG_DCB is
         unset. This results in namespace warnings (ice_sched.o: Externally
         defined symbols with no external references) when CONFIG_DCB is unset.
         To avoid this move ice_sched_query_elem from ice_sched.c to
         ice_common.c.
      Signed-off-by: NAnirudh Venkataramanan <anirudh.venkataramanan@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      7b9ffc76
  23. 25 3月, 2019 1 次提交
  24. 22 3月, 2019 1 次提交