1. 01 8月, 2019 6 次提交
    • 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
    • B
      ice: Always set prefena when configuring an Rx queue · c31a5c25
      Brett Creeley 提交于
      Currently we are always setting prefena to 0. This is causing the
      hardware to only fetch descriptors when there are none free in the cache
      for a received packet instead of prefetching when it has used the last
      descriptor regardless of incoming packets. Fix this by allowing the
      hardware to prefetch Rx descriptors.
      Signed-off-by: NBrett Creeley <brett.creeley@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      c31a5c25
    • T
      ice: Move vector base setup to PF VSI · 17bc6d07
      Tony Nguyen 提交于
      When interrupt tracking was refactored, during rebuild, the call to
      ice_vsi_setup_vector_base() was inadvertently removed from the PF VSI
      instead of being removed from the VF VSI. During reset, the failure to
      properly setup the vector base generates a call trace. Correct this so
      that resets/rebuilds properly complete.
      
      Fixes: cbe66bfe ("ice: Refactor interrupt tracking")
      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>
      17bc6d07
    • 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
    • P
      ice: add lp_advertising flow control support · 5a056cd7
      Paul Greenwalt 提交于
      Add support for reporting link partner advertising when
      ETHTOOL_GLINKSETTINGS defined. Get pause param reports the Tx/Rx
      pause configured, and then ethtool issues ETHTOOL_GSET ioctl and
      ice_get_settings_link_up reports the negotiated Tx/Rx pause. Negotiated
      pause frame report per IEEE 802.3-2005 table 288-3.
      
      $ ethtool --show-pause ens6f0
      Pause parameters for ens6f0:
      Autonegotiate:  on
      RX:             on
      TX:             on
      RX negotiated:  on
      TX negotiated:  on
      
      $ ethtool ens6f0
      Settings for ens6f0:
              Supported ports: [ FIBRE ]
              Supported link modes:   25000baseCR/Full
              Supported pause frame use: Symmetric
              Supports auto-negotiation: Yes
              Supported FEC modes: None BaseR RS
              Advertised link modes:  25000baseCR/Full
              Advertised pause frame use: Symmetric Receive-only
              Advertised auto-negotiation: Yes
              Advertised FEC modes: None BaseR RS
              Link partner advertised link modes:  Not reported
              Link partner advertised pause frame use: Symmetric
              Link partner advertised auto-negotiation: Yes
              Link partner advertised FEC modes: Not reported
              Speed: 25000Mb/s
              Duplex: Full
              Port: Direct Attach Copper
              PHYAD: 0
              Transceiver: internal
              Auto-negotiation: on
              Supports Wake-on: g
              Wake-on: g
              Current message level: 0x00000007 (7)
                                     drv probe link
              Link detected: yes
      
      When ETHTOOL_GLINKSETTINGS is not defined, get pause param reports the
      negotiated Tx/Rx pause.
      Signed-off-by: NPaul Greenwalt <paul.greenwalt@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      5a056cd7
    • Y
      staging/octeon: Fix build error without CONFIG_NETDEVICES · 6a7ce95d
      YueHaibing 提交于
      While do COMPILE_TEST build without CONFIG_NETDEVICES,
      we get Kconfig warning:
      
      WARNING: unmet direct dependencies detected for PHYLIB
        Depends on [n]: NETDEVICES [=n]
        Selected by [y]:
        - OCTEON_ETHERNET [=y] && STAGING [=y] && (CAVIUM_OCTEON_SOC && NETDEVICES [=n] || COMPILE_TEST [=y])
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Reported-by: NMark Brown <broonie@kernel.org>
      Fixes: 171a9bae ("staging/octeon: Allow test build on !MIPS")
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6a7ce95d
  2. 31 7月, 2019 34 次提交