1. 18 11月, 2018 1 次提交
  2. 16 11月, 2018 3 次提交
  3. 10 11月, 2018 3 次提交
    • H
      net: hns3: add PCIe FLR support for PF · 6b9a97ee
      Huazhong Tan 提交于
      This patch implements the .reset_prepare and .reset_done
      ops from pci framework to support the PF FLR.
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6b9a97ee
    • H
      net: hns3: add reset handling for VF when doing PF reset · aa5c4f17
      Huazhong Tan 提交于
      When PF performs a function reset, the hardware will reset both PF
      and all the VF belong to this PF. Hence, both PF's driver and VF's
      driver need to perform corresponding reset operations.
      
      Before PF driver asserting function reset to hardware, it firstly
      set up VF's hardware reset status, and inform the VF driver with
      HNAE3_VF_PF_FUNC_RESET, then VF driver sets this reset type to
      reset_pending and shechule reset task to stop IO and waits for the
      hardware reset status to clear. When PF driver has reinitialized the
      hardware and is ready to process mailbox from VF, PF driver clears
      VF's hardware reset status for VF to continue its reset process.
      
      Also, this patch uses readl_poll_timeout to simplify the hardware reset
      status waitting.
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NYunsheng Lin <linyunsheng@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aa5c4f17
    • H
      net: hns3: adjust VF's reset process · dea846e8
      Huazhong Tan 提交于
      Currently when VF need to reset itself, it will send a cmd to PF,
      after receiving the VF reset requset, PF sends a cmd to inform
      VF to enter the reset process and send a cmd to firmware to do the
      actual reset for the VF, it is possible that firmware has resetted
      the VF, but VF has not entered the reset process, which may cause
      IO not stopped problem when firmware is resetting VF.
      
      This patch fixes it by adjusting the VF reset process, when VF
      need to reset itself, it will enter the reset process first, and
      it will tell the PF to send cmd to firmware to reset itself.
      
      Add member reset_pending to struct hclgevf_dev, which indicates that
      there is reset event need to be processed by the VF's reset task, and
      the VF's reset task chooses the highest-level one and clears other
      low-level one when it processes reset_pending.
      
      hclge_inform_reset_assert_to_vf function is unused now, but it will
      be used to support the PF reset with VF working, so declare it in
      the header file.
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NYunsheng Lin <linyunsheng@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dea846e8
  4. 08 11月, 2018 3 次提交
  5. 01 11月, 2018 1 次提交
  6. 17 10月, 2018 1 次提交
  7. 13 10月, 2018 1 次提交
  8. 02 10月, 2018 1 次提交
  9. 29 9月, 2018 1 次提交
  10. 20 9月, 2018 2 次提交
  11. 23 8月, 2018 1 次提交
  12. 15 8月, 2018 2 次提交
  13. 21 7月, 2018 1 次提交
  14. 02 7月, 2018 2 次提交
  15. 29 5月, 2018 2 次提交
  16. 21 5月, 2018 1 次提交
    • X
      net: hns3: Fix for hns3 module is loaded multiple times problem · 3c7624d8
      Xi Wang 提交于
      If the hns3 driver has been built into kernel and then loaded with
      the same driver which built as KLM, it may trigger an error like
      below:
      
      [   20.009555] hns3: Hisilicon Ethernet Network Driver for Hip08 Family - version
      [   20.016789] hns3: Copyright (c) 2017 Huawei Corporation.
      [   20.022100] Error: Driver 'hns3' is already registered, aborting...
      [   23.517397] Unable to handle kernel NULL pointer dereference at virtual address 00000000
      ...
      [   23.691583] Process insmod (pid: 1982, stack limit = 0x00000000cd5f21cb)
      [   23.698270] Call trace:
      [   23.700705]  __list_del_entry_valid+0x2c/0xd8
      [   23.705049]  hnae3_unregister_client+0x68/0xa8
      [   23.709487]  hns3_init_module+0x98/0x1000 [hns3]
      [   23.714093]  do_one_initcall+0x5c/0x170
      [   23.717918]  do_init_module+0x64/0x1f4
      [   23.721654]  load_module+0x1d14/0x24b0
      [   23.725390]  SyS_init_module+0x158/0x208
      [   23.729300]  el0_svc_naked+0x30/0x34
      
      This patch fixes it by adding module version info.
      
      Fixes: 38caee9d ("net: hns3: Add support of the HNAE3 framework")
      Signed-off-by: NXi Wang <wangxi11@huawei.com>
      Signed-off-by: NSalil Mehta <salil.mehta@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3c7624d8
  17. 04 4月, 2018 1 次提交
  18. 23 3月, 2018 4 次提交
  19. 10 3月, 2018 1 次提交
  20. 12 1月, 2018 3 次提交
  21. 27 12月, 2017 1 次提交
  22. 15 12月, 2017 1 次提交
  23. 02 11月, 2017 1 次提交
  24. 24 10月, 2017 1 次提交
    • L
      net: hns3: fix a bug about hns3_clean_tx_ring · 24e750c4
      Lipeng 提交于
      The return value of hns3_clean_tx_ring means tx ring clean result.
      Return true means clean complete and there is no more pakcet need
      clean. Retrun false means there is packets need clean and napi need
      poll again. The last return of hns3_clean_tx_ring is
      "return !!budget" as budget will decrease when clean a buffer.
      
      If there is no valid BD in TX ring, return 0 for hns3_clean_tx_ring
      will cause napi poll again and never complete the napi poll. This
      patch fixes the bug.
      
      Fixes: 76ad4f0e (net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC)
      Signed-off-by: NLipeng <lipeng321@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      24e750c4
  25. 22 10月, 2017 1 次提交