1. 03 12月, 2021 2 次提交
  2. 02 12月, 2021 5 次提交
  3. 30 11月, 2021 1 次提交
  4. 29 11月, 2021 2 次提交
  5. 24 11月, 2021 2 次提交
  6. 10 11月, 2021 5 次提交
  7. 28 10月, 2021 1 次提交
  8. 27 10月, 2021 3 次提交
    • G
      net: hns3: ignore reset event before initialization process is done · 0251d196
      Guangbin Huang 提交于
      Currently, if there is a reset event triggered by RAS during device in
      initialization process, driver may run reset process concurrently with
      initialization process. In this case, it may cause problem. For example,
      the RSS indirection table may has not been alloc memory in initialization
      process yet, but it is used in reset process, it will cause a call trace
      like this:
      
      [61228.744836] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
      ...
      [61228.897677] Workqueue: hclgevf hclgevf_service_task [hclgevf]
      [61228.911390] pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--)
      [61228.918670] pc : hclgevf_set_rss_indir_table+0xb4/0x190 [hclgevf]
      [61228.927812] lr : hclgevf_set_rss_indir_table+0x90/0x190 [hclgevf]
      [61228.937248] sp : ffff8000162ebb50
      [61228.941087] x29: ffff8000162ebb50 x28: ffffb77add72dbc0 x27: ffff0820c7dc8080
      [61228.949516] x26: 0000000000000000 x25: ffff0820ad4fc880 x24: ffff0820c7dc8080
      [61228.958220] x23: ffff0820c7dc8090 x22: 00000000ffffffff x21: 0000000000000040
      [61228.966360] x20: ffffb77add72b9c0 x19: 0000000000000000 x18: 0000000000000030
      [61228.974646] x17: 0000000000000000 x16: ffffb77ae713feb0 x15: ffff0820ad4fcce8
      [61228.982808] x14: ffffffffffffffff x13: ffff8000962eb7f7 x12: 00003834ec70c960
      [61228.991990] x11: 00e0fafa8c206982 x10: 9670facc78a8f9a8 x9 : ffffb77add717530
      [61229.001123] x8 : ffff0820ad4fd6b8 x7 : 0000000000000000 x6 : 0000000000000011
      [61229.010249] x5 : 00000000000cb1b0 x4 : 0000000000002adb x3 : 0000000000000049
      [61229.018662] x2 : ffff8000162ebbb8 x1 : 0000000000000000 x0 : 0000000000000480
      [61229.027002] Call trace:
      [61229.030177]  hclgevf_set_rss_indir_table+0xb4/0x190 [hclgevf]
      [61229.039009]  hclgevf_rss_init_hw+0x128/0x1b4 [hclgevf]
      [61229.046809]  hclgevf_reset_rebuild+0x17c/0x69c [hclgevf]
      [61229.053862]  hclgevf_reset_service_task+0x4cc/0xa80 [hclgevf]
      [61229.061306]  hclgevf_service_task+0x6c/0x630 [hclgevf]
      [61229.068491]  process_one_work+0x1dc/0x48c
      [61229.074121]  worker_thread+0x15c/0x464
      [61229.078562]  kthread+0x168/0x16c
      [61229.082873]  ret_from_fork+0x10/0x18
      [61229.088221] Code: 7900e7f6 f904a683 d503201f 9101a3e2 (38616b43)
      [61229.095357] ---[ end trace 153661a538f6768c ]---
      
      To fix this problem, don't schedule reset task before initialization
      process is done.
      Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0251d196
    • Y
      net: hns3: change hclge/hclgevf workqueue to WQ_UNBOUND mode · f29da408
      Yufeng Mo 提交于
      Currently, the workqueue of hclge/hclgevf is executed on
      the CPU that initiates scheduling requests by default. In
      stress scenarios, the CPU may be busy and workqueue scheduling
      is completed after a long period of time. To avoid this
      situation and implement proper scheduling, use the WQ_UNBOUND
      mode instead. In this way, the workqueue can be performed on
      a relatively idle CPU.
      Signed-off-by: NYufeng Mo <moyufeng@huawei.com>
      Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f29da408
    • G
      net: hns3: fix pause config problem after autoneg disabled · 3bda2e5d
      Guangbin Huang 提交于
      If a TP port is configured by follow steps:
      1.ethtool -s ethx autoneg off speed 100 duplex full
      2.ethtool -A ethx rx on tx on
      3.ethtool -s ethx autoneg on(rx&tx negotiated pause results are off)
      4.ethtool -s ethx autoneg off speed 100 duplex full
      
      In step 3, driver will set rx&tx pause parameters of hardware to off as
      pause parameters negotiated with link partner are off.
      
      After step 4, the "ethtool -a ethx" command shows both rx and tx pause
      parameters are on. However, pause parameters of hardware are still off
      and port has no flow control function actually.
      
      To fix this problem, if autoneg is disabled, driver uses its saved
      parameters to restore pause of hardware. If the speed is not changed in
      this case, there is no link state changed for phy, it will cause the pause
      parameter is not taken effect, so we need to force phy to go down and up.
      
      Fixes: aacbe27e ("net: hns3: modify how pause options is displayed")
      Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3bda2e5d
  9. 25 10月, 2021 5 次提交
  10. 20 10月, 2021 1 次提交
  11. 15 10月, 2021 1 次提交
  12. 29 9月, 2021 2 次提交
  13. 20 9月, 2021 5 次提交
  14. 14 9月, 2021 2 次提交
    • G
      net: hns3: PF support get multicast MAC address space assigned by firmware · 5c56ff48
      Guangbin Huang 提交于
      The new firmware supports to divides the whole multicast MAC address space
      equally to functions of all PFs, and calculates the space size of each PF
      according to its function number.
      
      To support this feature, PF driver adds querying multicast MAC address
      space size from firmware and limits used number according to space size.
      Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5c56ff48
    • G
      net: hns3: PF support get unicast MAC address space assigned by firmware · e435a6b5
      Guangbin Huang 提交于
      Currently, there are two ways for PF to set the unicast MAC address space
      size: specified by config parameters in firmware or set to default value.
      
      That's mean if the config parameters in firmware is zero, driver will
      divide the whole unicast MAC address space equally to 8 PFs. However, in
      this case, the unicast MAC address space will be wasted a lot when the
      hardware actually has less then 8 PFs. And in the other hand, if one PF has
      much more VFs than other PFs, then each function of this PF will has much
      less address space than other PFs.
      
      In order to ameliorate the above two situations, introduce the third way
      of unicast MAC address space assignment: firmware divides the whole unicast
      MAC address space equally to functions of all PFs, and calculates the space
      size of each PF according to its function number. PF queries the space size
      by the querying device specification command when in initialization
      process.
      
      The third way assignment is lower priority than specified by config
      parameters, only if the config parameters is zero can be used, and if
      firmware does not support the third way assignment, then driver still
      divides the whole unicast MAC address space equally to 8 PFs.
      Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e435a6b5
  15. 13 9月, 2021 2 次提交
  16. 31 8月, 2021 1 次提交