Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 12 1月, 2020 5 次提交
    • H
      net: hns3: enlarge HCLGE_RESET_WAIT_CNT · 5bb784e9
      由 Huazhong Tan 提交于 
      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: NHuazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5bb784e9
    • H
      net: hns3: refactor the procedure of VF FLR · f28368bb
      由 Huazhong Tan 提交于 
      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: NHuazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f28368bb
    • H
      net: hns3: refactor the precedure of PF FLR · 8627bded
      由 Huazhong Tan 提交于 
      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: NHuazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8627bded
    • H
      net: hns3: split hclgevf_reset() into preparing and rebuilding part · 1cc9bc6e
      由 Huazhong Tan 提交于 
      hclgevf_reset() is a little bloated, and the process of VF FLR will
be separated from the reset task later. So this patch splits
hclgevf_reset() into hclgevf_reset_prepare() and hclge_reset_rebuild(),
then FLR can also reuse these two functions. Also moves HNAE3_UP_CLIENT
into hclgevf_reset_stack().
Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1cc9bc6e
    • H
      net: hns3: split hclge_reset() into preparing and rebuilding part · d4fa0656
      由 Huazhong Tan 提交于 
      hclge_reset() is a little bloated, and the process of PF FLR will
be separated from the reset task later. So this patch splits
hclge_reset() into hclge_reset_prepare() and hclge_reset_rebuild(),
then FLR can also reuse these two functions.

BTW, since hclge_clear_reset_cause() and hclge_reset_prepare_up()
will not affect the device, so in hclge_reset_rebuild(), these
functions are called without rtnl_lock.
Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d4fa0656
  3. 11 1月, 2020 35 次提交