1. 14 5月, 2023 1 次提交
  2. 24 3月, 2023 1 次提交
    • C
      net: hisilicon: Remove redundant pci_clear_master · fc3e07e8
      Cai Huoqing 提交于
      Remove pci_clear_master to simplify the code,
      the bus-mastering is also cleared in do_pci_disable_device,
      like this:
      ./drivers/pci/pci.c:2197
      static void do_pci_disable_device(struct pci_dev *dev)
      {
      	u16 pci_command;
      
      	pci_read_config_word(dev, PCI_COMMAND, &pci_command);
      	if (pci_command & PCI_COMMAND_MASTER) {
      		pci_command &= ~PCI_COMMAND_MASTER;
      		pci_write_config_word(dev, PCI_COMMAND, pci_command);
      	}
      
      	pcibios_disable_device(dev);
      }.
      And dev->is_busmaster is set to 0 in pci_disable_device.
      Signed-off-by: NCai Huoqing <cai.huoqing@linux.dev>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fc3e07e8
  3. 12 1月, 2023 1 次提交
  4. 24 12月, 2022 1 次提交
  5. 22 9月, 2022 1 次提交
  6. 07 9月, 2022 1 次提交
  7. 31 8月, 2022 1 次提交
  8. 01 7月, 2022 1 次提交
  9. 09 5月, 2022 2 次提交
  10. 20 4月, 2022 2 次提交
  11. 26 3月, 2022 1 次提交
  12. 07 2月, 2022 1 次提交
  13. 25 1月, 2022 1 次提交
  14. 05 1月, 2022 6 次提交
  15. 31 12月, 2021 4 次提交
  16. 29 11月, 2021 1 次提交
  17. 27 11月, 2021 1 次提交
    • G
      net: hns3: fix VF RSS failed problem after PF enable multi-TCs · 8d2ad993
      Guangbin Huang 提交于
      When PF is set to multi-TCs and configured mapping relationship between
      priorities and TCs, the hardware will active these settings for this PF
      and its VFs.
      
      In this case when VF just uses one TC and its rx packets contain priority,
      and if the priority is not mapped to TC0, as other TCs of VF is not valid,
      hardware always put this kind of packets to the queue 0. It cause this kind
      of packets of VF can not be used RSS function.
      
      To fix this problem, set tc mode of all unused TCs of VF to the setting of
      TC0, then rx packet with priority which map to unused TC will be direct to
      TC0.
      
      Fixes: e2cb1dec ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support")
      Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      8d2ad993
  18. 24 11月, 2021 1 次提交
  19. 10 11月, 2021 2 次提交
    • Y
      net: hns3: fix kernel crash when unload VF while it is being reset · e140c798
      Yufeng Mo 提交于
      When fully configure VLANs for a VF, then unload the VF while
      triggering a reset to PF, will cause a kernel crash because the
      irq is already uninit.
      
      [ 293.177579] ------------[ cut here ]------------
      [ 293.183502] kernel BUG at drivers/pci/msi.c:352!
      [ 293.189547] Internal error: Oops - BUG: 0 [#1] SMP
      ......
      [ 293.390124] Workqueue: hclgevf hclgevf_service_task [hclgevf]
      [ 293.402627] pstate: 80c00009 (Nzcv daif +PAN +UAO)
      [ 293.414324] pc : free_msi_irqs+0x19c/0x1b8
      [ 293.425429] lr : free_msi_irqs+0x18c/0x1b8
      [ 293.436545] sp : ffff00002716fbb0
      [ 293.446950] x29: ffff00002716fbb0 x28: 0000000000000000
      [ 293.459519] x27: 0000000000000000 x26: ffff45b91ea16b00
      [ 293.472183] x25: 0000000000000000 x24: ffffa587b08f4700
      [ 293.484717] x23: ffffc591ac30e000 x22: ffffa587b08f8428
      [ 293.497190] x21: ffffc591ac30e300 x20: 0000000000000000
      [ 293.509594] x19: ffffa58a062a8300 x18: 0000000000000000
      [ 293.521949] x17: 0000000000000000 x16: ffff45b91dcc3f48
      [ 293.534013] x15: 0000000000000000 x14: 0000000000000000
      [ 293.545883] x13: 0000000000000040 x12: 0000000000000228
      [ 293.557508] x11: 0000000000000020 x10: 0000000000000040
      [ 293.568889] x9 : ffff45b91ea1e190 x8 : ffffc591802d0000
      [ 293.580123] x7 : ffffc591802d0148 x6 : 0000000000000120
      [ 293.591190] x5 : ffffc591802d0000 x4 : 0000000000000000
      [ 293.602015] x3 : 0000000000000000 x2 : 0000000000000000
      [ 293.612624] x1 : 00000000000004a4 x0 : ffffa58a1e0c6b80
      [ 293.623028] Call trace:
      [ 293.630340] free_msi_irqs+0x19c/0x1b8
      [ 293.638849] pci_disable_msix+0x118/0x140
      [ 293.647452] pci_free_irq_vectors+0x20/0x38
      [ 293.656081] hclgevf_uninit_msi+0x44/0x58 [hclgevf]
      [ 293.665309] hclgevf_reset_rebuild+0x1ac/0x2e0 [hclgevf]
      [ 293.674866] hclgevf_reset+0x358/0x400 [hclgevf]
      [ 293.683545] hclgevf_reset_service_task+0xd0/0x1b0 [hclgevf]
      [ 293.693325] hclgevf_service_task+0x4c/0x2e8 [hclgevf]
      [ 293.702307] process_one_work+0x1b0/0x448
      [ 293.710034] worker_thread+0x54/0x468
      [ 293.717331] kthread+0x134/0x138
      [ 293.724114] ret_from_fork+0x10/0x18
      [ 293.731324] Code: f940b000 b4ffff00 a903e7b8 f90017b6 (d4210000)
      
      This patch fixes the problem by waiting for the VF reset done
      while unloading the VF.
      
      Fixes: e2cb1dec ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support")
      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>
      e140c798
    • J
      net: hns3: fix ROCE base interrupt vector initialization bug · beb27ca4
      Jie Wang 提交于
      Currently, NIC init ROCE interrupt vector with MSIX interrupt. But ROCE use
      pci_irq_vector() to get interrupt vector, which adds the relative interrupt
      vector again and gets wrong interrupt vector.
      
      So fixes it by assign relative interrupt vector to ROCE instead of MSIX
      interrupt vector and delete the unused struct member base_msi_vector
      declaration of hclgevf_dev.
      
      Fixes: 46a3df9f ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support")
      Signed-off-by: NJie Wang <wangjie125@huawei.com>
      Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      beb27ca4
  20. 27 10月, 2021 2 次提交
    • 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
  21. 20 10月, 2021 1 次提交
  22. 15 10月, 2021 1 次提交
  23. 20 9月, 2021 1 次提交
  24. 13 9月, 2021 1 次提交
    • Jiaran Zhang's avatar
      net: hns3: fix the timing issue of VF clearing interrupt sources · 427900d2
      Jiaran Zhang 提交于
      Currently, the VF does not clear the interrupt source immediately after
      receiving the interrupt. As a result, if the second interrupt task is
      triggered when processing the first interrupt task, clearing the
      interrupt source before exiting will clear the interrupt sources of the
      two tasks at the same time. As a result, no interrupt is triggered for
      the second task. The VF detects the missed message only when the next
      interrupt is generated.
      
      Clearing it immediately after executing check_evt_cause ensures that:
      1. Even if two interrupt tasks are triggered at the same time, they can
      be processed.
      2. If the second task is triggered during the processing of the first
      task and the interrupt source is not cleared, the interrupt is reported
      after vector0 is enabled.
      
      Fixes: b90fcc5b ("net: hns3: add reset handling for VF when doing Core/Global/IMP reset")
      Signed-off-by: Jiaran Zhang's avatarJiaran Zhang <zhangjiaran@huawei.com>
      Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      427900d2
  25. 27 8月, 2021 1 次提交
  26. 26 8月, 2021 2 次提交
  27. 24 8月, 2021 1 次提交