1. 06 8月, 2018 4 次提交
  2. 17 7月, 2018 1 次提交
  3. 10 7月, 2018 1 次提交
    • M
      bnxt_en: Do not modify max IRQ count after RDMA driver requests/frees IRQs. · 30f52947
      Michael Chan 提交于
      Calling bnxt_set_max_func_irqs() to modify the max IRQ count requested or
      freed by the RDMA driver is flawed.  The max IRQ count is checked when
      re-initializing the IRQ vectors and this can happen multiple times
      during ifup or ethtool -L.  If the max IRQ is reduced and the RDMA
      driver is operational, we may not initailize IRQs correctly.  This
      problem shows up on VFs with very small number of MSIX.
      
      There is no other logic that relies on the IRQ count excluding the ones
      used by RDMA.  So we fix it by just removing the call to subtract or
      add the IRQs used by RDMA.
      
      Fixes: a588e458 ("bnxt_en: Add interface to support RDMA driver.")
      Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      30f52947
  4. 08 5月, 2018 2 次提交
    • V
      bnxt_en: Read phy eeprom A2h address only when optical diagnostics is supported. · 7328a23c
      Vasundhara Volam 提交于
      For SFP+ modules, 0xA2 page is available only when Diagnostic Monitoring
      Type [Address A0h, Byte 92] is implemented. Extend bnxt_get_module_info(),
      to read optical diagnostics support at offset 92(0x5c) and set eeprom_len
      length to ETH_MODULE_SFF_8436_LEN (to exclude A2 page), if dianostics is
      not supported.
      
      Also in bnxt_get_module_info(), module id is read from offset 0x5e which
      is not correct. It was working by accident, as offset was not effective
      without setting enables flag in the firmware request. SFP module id is
      present at location 0. Fix this by removing the offset and read it
      from location 0.
      Signed-off-by: NVasundhara Volam <vasundhara-v.volam@broadcom.com>
      Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7328a23c
    • 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
  5. 28 4月, 2018 3 次提交
  6. 01 4月, 2018 7 次提交
  7. 27 3月, 2018 1 次提交
  8. 12 3月, 2018 1 次提交
  9. 18 1月, 2018 7 次提交
  10. 11 1月, 2018 1 次提交
  11. 06 1月, 2018 1 次提交
  12. 27 10月, 2017 6 次提交
  13. 15 10月, 2017 2 次提交
  14. 29 8月, 2017 3 次提交