1. 24 9月, 2018 1 次提交
    • E
      bnxt: remove ndo_poll_controller · 58e0e22b
      Eric Dumazet 提交于
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC). This capture
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      bnxt uses NAPI for TX completions, so we better let core
      networking stack call the napi->poll() to avoid the capture.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Michael Chan <michael.chan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      58e0e22b
  2. 17 9月, 2018 1 次提交
  3. 04 9月, 2018 3 次提交
  4. 08 8月, 2018 1 次提交
  5. 06 8月, 2018 9 次提交
  6. 17 7月, 2018 1 次提交
  7. 10 7月, 2018 5 次提交
  8. 30 6月, 2018 1 次提交
  9. 26 6月, 2018 1 次提交
  10. 26 5月, 2018 1 次提交
    • B
      bnxt_en: Report PCIe link properties with pcie_print_link_status() · af125b75
      Bjorn Helgaas 提交于
      Previously the driver used pcie_get_minimum_link() to warn when the NIC
      is in a slot that can't supply as much bandwidth as the NIC could use.
      
      pcie_get_minimum_link() can be misleading because it finds the slowest link
      and the narrowest link (which may be different links) without considering
      the total bandwidth of each link.  For a path with a 16 GT/s x1 link and a
      2.5 GT/s x16 link, it returns 2.5 GT/s x1, which corresponds to 250 MB/s of
      bandwidth, not the true available bandwidth of about 1969 MB/s for a
      16 GT/s x1 link.
      
      Use pcie_print_link_status() to report PCIe link speed and possible
      limitations instead of implementing this in the driver itself.  This finds
      the slowest link in the path to the device by computing the total bandwidth
      of each link and compares that with the capabilities of the device.
      
      The dmesg change is:
      
        - PCIe: Speed %s Width x%d
        + %u.%03u Gb/s available PCIe bandwidth (%s x%d link)
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      af125b75
  11. 08 5月, 2018 3 次提交
    • M
      bnxt_en: Always forward VF MAC address to the PF. · 707e7e96
      Michael Chan 提交于
      The current code already forwards the VF MAC address to the PF, except
      in one case.  If the VF driver gets a valid MAC address from the firmware
      during probe time, it will not forward the MAC address to the PF,
      incorrectly assuming that the PF already knows the MAC address.  This
      causes "ip link show" to show zero VF MAC addresses for this case.
      
      This assumption is not correct.  Newer firmware remembers the VF MAC
      address last used by the VF and provides it to the VF driver during
      probe.  So we need to always forward the VF MAC address to the PF.
      
      The forwarded MAC address may now be the PF assigned MAC address and so we
      need to make sure we approve it for this case.
      Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      707e7e96
    • M
      bnxt_en: Check unsupported speeds in bnxt_update_link() on PF only. · dac04907
      Michael Chan 提交于
      Only non-NPAR PFs need to actively check and manage unsupported link
      speeds.  NPAR functions and VFs do not control the link speed and
      should skip the unsupported speed detection logic, to avoid warning
      messages from firmware rejecting the unsupported firmware calls.
      Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dac04907
    • M
      bnxt_en: Fix firmware message delay loop regression. · cc559c1a
      Michael Chan 提交于
      A recent change to reduce delay granularity waiting for firmware
      reponse has caused a regression.  With a tighter delay loop,
      the driver may see the beginning part of the response faster.
      The original 5 usec delay to wait for the rest of the message
      is not long enough and some messages are detected as invalid.
      
      Increase the maximum wait time from 5 usec to 20 usec.  Also, fix
      the debug message that shows the total delay time for the response
      when the message times out.  With the new logic, the delay time
      is not fixed per iteration of the loop, so we define a macro to
      show the total delay time.
      
      Fixes: 9751e8e7 ("bnxt_en: reduce timeout on initial HWRM calls")
      Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cc559c1a
  12. 28 4月, 2018 9 次提交
  13. 12 4月, 2018 2 次提交
  14. 01 4月, 2018 2 次提交