1. 05 2月, 2020 3 次提交
  2. 04 2月, 2020 6 次提交
    • Y
      qed: Remove set but not used variable 'p_link' · 83b43045
      YueHaibing 提交于
      Fixes gcc '-Wunused-but-set-variable' warning:
      
      drivers/net/ethernet/qlogic/qed/qed_cxt.c: In function 'qed_qm_init_pf':
      drivers/net/ethernet/qlogic/qed/qed_cxt.c:1401:29: warning:
       variable 'p_link' set but not used [-Wunused-but-set-variable]
      
      commit 92fae6fb ("qed: FW 8.42.2.0 Queue Manager changes")
      leave behind this unused variable.
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      83b43045
    • M
      bnxt_en: Fix TC queue mapping. · 18e4960c
      Michael Chan 提交于
      The driver currently only calls netdev_set_tc_queue when the number of
      TCs is greater than 1.  Instead, the comparison should be greater than
      or equal to 1.  Even with 1 TC, we need to set the queue mapping.
      
      This bug can cause warnings when the number of TCs is changed back to 1.
      
      Fixes: 7809592d ("bnxt_en: Enable MSIX early in bnxt_init_one().")
      Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      18e4960c
    • V
      bnxt_en: Fix logic that disables Bus Master during firmware reset. · d4073028
      Vasundhara Volam 提交于
      The current logic that calls pci_disable_device() in __bnxt_close_nic()
      during firmware reset is flawed.  If firmware is still alive, we're
      disabling the device too early, causing some firmware commands to
      not reach the firmware.
      
      Fix it by moving the logic to bnxt_reset_close().  If firmware is
      in fatal condition, we call pci_disable_device() before we free
      any of the rings to prevent DMA corruption of the freed rings.  If
      firmware is still alive, we call pci_disable_device() after the
      last firmware message has been sent.
      
      Fixes: 3bc7d4a3 ("bnxt_en: Add BNXT_STATE_IN_FW_RESET state.")
      Signed-off-by: NVasundhara Volam <vasundhara-v.volam@broadcom.com>
      Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      d4073028
    • M
      bnxt_en: Fix RDMA driver failure with SRIOV after firmware reset. · 12de2ead
      Michael Chan 提交于
      bnxt_ulp_start() needs to be called before SRIOV is re-enabled after
      firmware reset.  Re-enabling SRIOV may consume all the resources and
      may cause the RDMA driver to fail to get MSIX and other resources.
      Fix it by calling bnxt_ulp_start() first before calling
      bnxt_reenable_sriov().
      
      We re-arrange the logic so that we call bnxt_ulp_start() and
      bnxt_reenable_sriov() in proper sequence in bnxt_fw_reset_task() and
      bnxt_open().  The former is the normal coordinated firmware reset sequence
      and the latter is firmware reset while the function is down.  This new
      logic is now more straight forward and will now fix both scenarios.
      
      Fixes: f3a6d206 ("bnxt_en: Call bnxt_ulp_stop()/bnxt_ulp_start() during error recovery.")
      Reported-by: NVasundhara Volam <vasundhara-v.volam@broadcom.com>
      Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      12de2ead
    • M
      bnxt_en: Refactor logic to re-enable SRIOV after firmware reset detected. · c16d4ee0
      Michael Chan 提交于
      Put the current logic in bnxt_open() to re-enable SRIOV after detecting
      firmware reset into a new function bnxt_reenable_sriov().  This call
      needs to be invoked in the firmware reset path also in the next patch.
      Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      c16d4ee0
    • N
      net: stmmac: Delete txtimer in suspend() · 14b41a29
      Nicolin Chen 提交于
      When running v5.5 with a rootfs on NFS, memory abort may happen in
      the system resume stage:
       Unable to handle kernel paging request at virtual address dead00000000012a
       [dead00000000012a] address between user and kernel address ranges
       pc : run_timer_softirq+0x334/0x3d8
       lr : run_timer_softirq+0x244/0x3d8
       x1 : ffff800011cafe80 x0 : dead000000000122
       Call trace:
        run_timer_softirq+0x334/0x3d8
        efi_header_end+0x114/0x234
        irq_exit+0xd0/0xd8
        __handle_domain_irq+0x60/0xb0
        gic_handle_irq+0x58/0xa8
        el1_irq+0xb8/0x180
        arch_cpu_idle+0x10/0x18
        do_idle+0x1d8/0x2b0
        cpu_startup_entry+0x24/0x40
        secondary_start_kernel+0x1b4/0x208
       Code: f9000693 a9400660 f9000020 b4000040 (f9000401)
       ---[ end trace bb83ceeb4c482071 ]---
       Kernel panic - not syncing: Fatal exception in interrupt
       SMP: stopping secondary CPUs
       SMP: failed to stop secondary CPUs 2-3
       Kernel Offset: disabled
       CPU features: 0x00002,2300aa30
       Memory Limit: none
       ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
      
      It's found that stmmac_xmit() and stmmac_resume() sometimes might
      run concurrently, possibly resulting in a race condition between
      mod_timer() and setup_timer(), being called by stmmac_xmit() and
      stmmac_resume() respectively.
      
      Since the resume() runs setup_timer() every time, it'd be safer to
      have del_timer_sync() in the suspend() as the counterpart.
      Signed-off-by: NNicolin Chen <nicoleotsuka@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      14b41a29
  3. 02 2月, 2020 2 次提交
  4. 01 2月, 2020 3 次提交
  5. 29 1月, 2020 1 次提交
  6. 27 1月, 2020 25 次提交