1. 19 5月, 2021 3 次提交
    • H
      net: hns3: fix user's coalesce configuration lost issue · 73a13d8d
      Huazhong Tan 提交于
      Currently, when adaptive is on, the user's coalesce configuration
      may be overwritten by the dynamic one. The reason is that user's
      configurations are saved in struct hns3_enet_tqp_vector whose
      value maybe changed by the dynamic algorithm. To fix it, use
      struct hns3_nic_priv instead of struct hns3_enet_tqp_vector to
      save and get the user's configuration.
      
      BTW, operations of storing and restoring coalesce info in the reset
      process are unnecessary now, so remove them as well.
      
      Fixes: 434776a5 ("net: hns3: add ethtool_ops.set_coalesce support to PF")
      Fixes: 7e96adc4 ("net: hns3: add ethtool_ops.get_coalesce support to PF")
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      73a13d8d
    • J
      net: hns3: put off calling register_netdev() until client initialize complete · a289a7e5
      Jian Shen 提交于
      Currently, the netdevice is registered before client initializing
      complete. So there is a timewindow between netdevice available
      and usable. In this case, if user try to change the channel number
      or ring param, it may cause the hns3_set_rx_cpu_rmap() being called
      twice, and report bug.
      
      [47199.416502] hns3 0000:35:00.0 eth1: set channels: tqp_num=1, rxfh=0
      [47199.430340] hns3 0000:35:00.0 eth1: already uninitialized
      [47199.438554] hns3 0000:35:00.0: rss changes from 4 to 1
      [47199.511854] hns3 0000:35:00.0: Channels changed, rss_size from 4 to 1, tqps from 4 to 1
      [47200.163524] ------------[ cut here ]------------
      [47200.171674] kernel BUG at lib/cpu_rmap.c:142!
      [47200.177847] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
      [47200.185259] Modules linked in: hclge(+) hns3(-) hns3_cae(O) hns_roce_hw_v2 hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O) [last unloaded: hclge]
      [47200.205912] CPU: 1 PID: 8260 Comm: ethtool Tainted: G           O      5.11.0-rc3+ #1
      [47200.215601] Hardware name:  , xxxxxx 02/04/2021
      [47200.223052] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)
      [47200.230188] pc : cpu_rmap_add+0x38/0x40
      [47200.237472] lr : irq_cpu_rmap_add+0x84/0x140
      [47200.243291] sp : ffff800010e93a30
      [47200.247295] x29: ffff800010e93a30 x28: ffff082100584880
      [47200.254155] x27: 0000000000000000 x26: 0000000000000000
      [47200.260712] x25: 0000000000000000 x24: 0000000000000004
      [47200.267241] x23: ffff08209ba03000 x22: ffff08209ba038c0
      [47200.273789] x21: 000000000000003f x20: ffff0820e2bc1680
      [47200.280400] x19: ffff0820c970ec80 x18: 00000000000000c0
      [47200.286944] x17: 0000000000000000 x16: ffffb43debe4a0d0
      [47200.293456] x15: fffffc2082990600 x14: dead000000000122
      [47200.300059] x13: ffffffffffffffff x12: 000000000000003e
      [47200.306606] x11: ffff0820815b8080 x10: ffff53e411988000
      [47200.313171] x9 : 0000000000000000 x8 : ffff0820e2bc1700
      [47200.319682] x7 : 0000000000000000 x6 : 000000000000003f
      [47200.326170] x5 : 0000000000000040 x4 : ffff800010e93a20
      [47200.332656] x3 : 0000000000000004 x2 : ffff0820c970ec80
      [47200.339168] x1 : ffff0820e2bc1680 x0 : 0000000000000004
      [47200.346058] Call trace:
      [47200.349324]  cpu_rmap_add+0x38/0x40
      [47200.354300]  hns3_set_rx_cpu_rmap+0x6c/0xe0 [hns3]
      [47200.362294]  hns3_reset_notify_init_enet+0x1cc/0x340 [hns3]
      [47200.370049]  hns3_change_channels+0x40/0xb0 [hns3]
      [47200.376770]  hns3_set_channels+0x12c/0x2a0 [hns3]
      [47200.383353]  ethtool_set_channels+0x140/0x250
      [47200.389772]  dev_ethtool+0x714/0x23d0
      [47200.394440]  dev_ioctl+0x4cc/0x640
      [47200.399277]  sock_do_ioctl+0x100/0x2a0
      [47200.404574]  sock_ioctl+0x28c/0x470
      [47200.409079]  __arm64_sys_ioctl+0xb4/0x100
      [47200.415217]  el0_svc_common.constprop.0+0x84/0x210
      [47200.422088]  do_el0_svc+0x28/0x34
      [47200.426387]  el0_svc+0x28/0x70
      [47200.431308]  el0_sync_handler+0x1a4/0x1b0
      [47200.436477]  el0_sync+0x174/0x180
      [47200.441562] Code: 11000405 79000c45 f8247861 d65f03c0 (d4210000)
      [47200.448869] ---[ end trace a01efe4ce42e5f34 ]---
      
      The process is like below:
      excuting hns3_client_init
      |
      register_netdev()
      |                           hns3_set_channels()
      |                           |
      hns3_set_rx_cpu_rmap()      hns3_reset_notify_uninit_enet()
      |                               |
      |                            quit without calling function
      |                            hns3_free_rx_cpu_rmap for flag
      |                            HNS3_NIC_STATE_INITED is unset.
      |                           |
      |                           hns3_reset_notify_init_enet()
      |                               |
      set HNS3_NIC_STATE_INITED    call hns3_set_rx_cpu_rmap()-- crash
      
      Fix it by calling register_netdev() at the end of function
      hns3_client_init().
      
      Fixes: 08a10068 ("net: hns3: re-organize vector handle")
      Signed-off-by: NJian Shen <shenjian15@huawei.com>
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a289a7e5
    • Jiaran Zhang's avatar
      net: hns3: fix incorrect resp_msg issue · a710b9ff
      Jiaran Zhang 提交于
      In hclge_mbx_handler(), if there are two consecutive mailbox
      messages that requires resp_msg, the resp_msg is not cleared
      after processing the first message, which will cause the resp_msg
      data of second message incorrect.
      
      Fix it by clearing the resp_msg before processing every mailbox
      message.
      
      Fixes: bb5790b7 ("net: hns3: refactor mailbox response scheme between PF and VF")
      Signed-off-by: Jiaran Zhang's avatarJiaran Zhang <zhangjiaran@huawei.com>
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a710b9ff
  2. 01 5月, 2021 4 次提交
  3. 30 4月, 2021 3 次提交
  4. 20 4月, 2021 3 次提交
  5. 16 4月, 2021 2 次提交
  6. 14 4月, 2021 1 次提交
    • M
      of: net: pass the dst buffer to of_get_mac_address() · 83216e39
      Michael Walle 提交于
      of_get_mac_address() returns a "const void*" pointer to a MAC address.
      Lately, support to fetch the MAC address by an NVMEM provider was added.
      But this will only work with platform devices. It will not work with
      PCI devices (e.g. of an integrated root complex) and esp. not with DSA
      ports.
      
      There is an of_* variant of the nvmem binding which works without
      devices. The returned data of a nvmem_cell_read() has to be freed after
      use. On the other hand the return of_get_mac_address() points to some
      static data without a lifetime. The trick for now, was to allocate a
      device resource managed buffer which is then returned. This will only
      work if we have an actual device.
      
      Change it, so that the caller of of_get_mac_address() has to supply a
      buffer where the MAC address is written to. Unfortunately, this will
      touch all drivers which use the of_get_mac_address().
      
      Usually the code looks like:
      
        const char *addr;
        addr = of_get_mac_address(np);
        if (!IS_ERR(addr))
          ether_addr_copy(ndev->dev_addr, addr);
      
      This can then be simply rewritten as:
      
        of_get_mac_address(np, ndev->dev_addr);
      
      Sometimes is_valid_ether_addr() is used to test the MAC address.
      of_get_mac_address() already makes sure, it just returns a valid MAC
      address. Thus we can just test its return code. But we have to be
      careful if there are still other sources for the MAC address before the
      of_get_mac_address(). In this case we have to keep the
      is_valid_ether_addr() call.
      
      The following coccinelle patch was used to convert common cases to the
      new style. Afterwards, I've manually gone over the drivers and fixed the
      return code variable: either used a new one or if one was already
      available use that. Mansour Moufid, thanks for that coccinelle patch!
      
      <spml>
      @a@
      identifier x;
      expression y, z;
      @@
      - x = of_get_mac_address(y);
      + x = of_get_mac_address(y, z);
        <...
      - ether_addr_copy(z, x);
        ...>
      
      @@
      identifier a.x;
      @@
      - if (<+... x ...+>) {}
      
      @@
      identifier a.x;
      @@
        if (<+... x ...+>) {
            ...
        }
      - else {}
      
      @@
      identifier a.x;
      expression e;
      @@
      - if (<+... x ...+>@e)
      -     {}
      - else
      + if (!(e))
            {...}
      
      @@
      expression x, y, z;
      @@
      - x = of_get_mac_address(y, z);
      + of_get_mac_address(y, z);
        ... when != x
      </spml>
      
      All drivers, except drivers/net/ethernet/aeroflex/greth.c, were
      compile-time tested.
      Suggested-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NMichael Walle <michael@walle.cc>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      83216e39
  7. 13 4月, 2021 1 次提交
  8. 10 4月, 2021 1 次提交
  9. 09 4月, 2021 2 次提交
  10. 07 4月, 2021 1 次提交
  11. 06 4月, 2021 3 次提交
  12. 02 4月, 2021 1 次提交
  13. 30 3月, 2021 9 次提交
  14. 29 3月, 2021 1 次提交
    • L
      net: hns3: no return statement in hclge_clear_arfs_rules · 54422bd4
      Liu Jian 提交于
      drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c: In function 'hclge_clear_arfs_rules':
      drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c:7173:1: error: no return statement in function returning non-void [-Werror=return-type]
       7173 | }
            | ^
      cc1: some warnings being treated as errors
      make[6]: *** [scripts/Makefile.build:273: drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.o] Error 1
      make[5]: *** [scripts/Makefile.build:534: drivers/net/ethernet/hisilicon/hns3/hns3pf] Error 2
      make[4]: *** [scripts/Makefile.build:534: drivers/net/ethernet/hisilicon/hns3] Error 2
      make[4]: *** Waiting for unfinished jobs....
      make[3]: *** [scripts/Makefile.build:534: drivers/net/ethernet/hisilicon] Error 2
      make[2]: *** [scripts/Makefile.build:534: drivers/net/ethernet] Error 2
      make[1]: *** [scripts/Makefile.build:534: drivers/net] Error 2
      make[1]: *** Waiting for unfinished jobs....
      make: *** [Makefile:1980: drivers] Error 2
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Signed-off-by: NLiu Jian <liujian56@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      54422bd4
  15. 27 3月, 2021 5 次提交