1. 14 Jan, 2020 20 commits
  2. 13 Jan, 2020 3 commits
  3. 12 Jan, 2020 11 commits
  4. 11 Jan, 2020 6 commits
    • David S. Miller's avatar
      Merge branch 'hns3-next' · 5c9166f0
      David S. Miller authored
      Huazhong Tan says:
      
      ====================
      net: hns3: add some misc update about reset issue
      
      This series includes some misc update relating to reset issue.
      [patch 1/7] & [patch 2/7] splits hclge_reset()/hclgevf_reset()
      into two parts: preparing and rebuilding. Since the procedure
      of FLR should be separated out from the reset task([patch 3/7 &
      patch 3/7]), then the FLR's processing can reuse these codes.
      
      pci_error_handlers.reset_prepare() is void type function, so
      [patch 6/7] & [patch 7/7] factor some codes related to PF
      function reset to make the preparing done before .reset_prepare()
      return.
      
      BTW, [patch 5/7] enlarges the waiting time of reset for matching
      the hardware's.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5c9166f0
    • Huazhong Tan's avatar
      net: hns3: refactor the notification scheme of PF reset · c7554dcd
      Huazhong Tan authored
      hclge_reset_prepare_down() is only used to inform VF that PF is
      going to do function reset, then using hclge_func_reset_sync_vf()
      in hclge_reset_prepare_wait() to query whether VF is ready before
      asserting PF function reset. To make the code more readable,
      this patch uses a new function hclge_function_reset_notify_vf()
      to do this job.
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c7554dcd
    • Huazhong Tan's avatar
      net: hns3: modify hclge_func_reset_sync_vf()'s return type to void · c3106cac
      Huazhong Tan authored
      When synchronizes with VFs fail before PF function reset,
      PF driver should go on its function reset, otherwise it
      can not run normally anymore. So, hclge_func_reset_sync_vf()
      should not affect the processing of PF reset, this patch
      modifies its return type to void.
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c3106cac
    • Huazhong Tan's avatar
      net: hns3: enlarge HCLGE_RESET_WAIT_CNT · 5bb784e9
      Huazhong Tan authored
      When the load of firmware is high, its reset task may takes
      more time(which will be as long as 35 seconds). So this
      patch modifies HCLGE_RESET_WAIT_CNT to match the firmware's.
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5bb784e9
    • Huazhong Tan's avatar
      net: hns3: refactor the procedure of VF FLR · f28368bb
      Huazhong Tan authored
      Currently, the actual work of VF FLR is handled in the reset task,
      which is asynchronous. So in some case, if the preparing and
      rebuilding are not done, then the VF FLR will trigger some problems,
      for example, makes hardware go into chaos.
      
      So this patch separates the process of VF FLR from reset task, and
      adds a semaphore to serialize this reset and others.
      
      When FLR's preparing fails, if there has other higher level reset
      pending or failing times less than the HCLGE_FLR_RETRY_CNT, this
      preparing should be retried, otherwise it will get into a wrong state.
      
      BTW, while the hardware reports misc interrupt during pcie_flr(),
      the driver can not receive this interrupt anymore, so disable it
      when hclgevf_flr_prepare() return, and re-enable it when enter
      hclgevf_flr_done().
      
      Avoid declaring internal function hclgevf_enable_vector(), this patch
      also moves its definition forward, and removes unused enum
      hnae3_flr_state.
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f28368bb
    • Huazhong Tan's avatar
      net: hns3: refactor the precedure of PF FLR · 8627bded
      Huazhong Tan authored
      Currently, the actual work of PF FLR is handled in the reset task,
      which is asynchronous. So in some case, if the preparing and
      rebuilding are not done, then the PF FLR will trigger some problems,
      for example, makes hardware go into chaos.
      
      So this patch separates the process of PF FLR from reset task, and
      adds a semaphore to serialize this reset and others.
      
      When FLR's preparing fails, if there has other higher level reset
      pending or failing times less than the HCLGE_FLR_RETRY_CNT, this
      preparing should be retried, otherwise PF and its VF may get into
      wrong state.
      
      BTW, while the hardware reports misc interrupt during pcie_flr(),
      the driver can not receive this interrupt anymore, so disable it
      when hclge_flr_prepare() return, and re-enable it when enter
      hclge_flr_done().
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8627bded