- 26 4月, 2021 1 次提交
-
-
由 Guangbin Huang 提交于
stable inclusion from stable-5.10.30 commit f780a08088274280d10b356b68297d32dbe33dc8 bugzilla: 51791 -------------------------------- [ Upstream commit ed7bedd2 ] Currently, the VF down state bit is cleared after VF sending link status request command. There is problem that when VF gets link status replied from PF, the down state bit may still set as 1. In this case, the link status replied from PF will be ignored and always set VF link status to down. To fix this problem, clear VF down state bit before VF requests link status. Fixes: e2cb1dec ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support") Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: N Weilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 27 1月, 2021 1 次提交
-
-
由 Jian Shen 提交于
stable inclusion from stable-5.10.8 commit 799d8080f9031f9a96e257a4a8374455403926cc bugzilla: 47450 -------------------------------- [ Upstream commit ab6e32d2 ] For DEVICE_VERSION_V2, the hardware only supports src-ip, dst-ip and verification-tag for rss tuple set of sctp6 packet. For DEVICE_VERSION_V3, the hardware supports src-port and dst-port as well. Currently, when user queries the sctp6 rss tuples info, some unsupported information will be showed on V2. So add a check for hardware version when initializing and queries sctp6 rss tuple to fix this issue. Fixes: 46a3df9f ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") 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> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
- 27 10月, 2020 1 次提交
-
-
由 Zenghui Yu 提交于
When unbinding the hns3 driver with the HNS3 VF, I got the following kernel panic: [ 265.709989] Unable to handle kernel paging request at virtual address ffff800054627000 [ 265.717928] Mem abort info: [ 265.720740] ESR = 0x96000047 [ 265.723810] EC = 0x25: DABT (current EL), IL = 32 bits [ 265.729126] SET = 0, FnV = 0 [ 265.732195] EA = 0, S1PTW = 0 [ 265.735351] Data abort info: [ 265.738227] ISV = 0, ISS = 0x00000047 [ 265.742071] CM = 0, WnR = 1 [ 265.745055] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000009b54000 [ 265.751753] [ffff800054627000] pgd=0000202ffffff003, p4d=0000202ffffff003, pud=00002020020eb003, pmd=00000020a0dfc003, pte=0000000000000000 [ 265.764314] Internal error: Oops: 96000047 [#1] SMP [ 265.830357] CPU: 61 PID: 20319 Comm: bash Not tainted 5.9.0+ #206 [ 265.836423] Hardware name: Huawei TaiShan 2280 V2/BC82AMDDA, BIOS 1.05 09/18/2019 [ 265.843873] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--) [ 265.843890] pc : hclgevf_cmd_uninit+0xbc/0x300 [ 265.861988] lr : hclgevf_cmd_uninit+0xb0/0x300 [ 265.861992] sp : ffff80004c983b50 [ 265.881411] pmr_save: 000000e0 [ 265.884453] x29: ffff80004c983b50 x28: ffff20280bbce500 [ 265.889744] x27: 0000000000000000 x26: 0000000000000000 [ 265.895034] x25: ffff800011a1f000 x24: ffff800011a1fe90 [ 265.900325] x23: ffff0020ce9b00d8 x22: ffff0020ce9b0150 [ 265.905616] x21: ffff800010d70e90 x20: ffff800010d70e90 [ 265.910906] x19: ffff0020ce9b0080 x18: 0000000000000004 [ 265.916198] x17: 0000000000000000 x16: ffff800011ae32e8 [ 265.916201] x15: 0000000000000028 x14: 0000000000000002 [ 265.916204] x13: ffff800011ae32e8 x12: 0000000000012ad8 [ 265.946619] x11: ffff80004c983b50 x10: 0000000000000000 [ 265.951911] x9 : ffff8000115d0888 x8 : 0000000000000000 [ 265.951914] x7 : ffff800011890b20 x6 : c0000000ffff7fff [ 265.951917] x5 : ffff80004c983930 x4 : 0000000000000001 [ 265.951919] x3 : ffffa027eec1b000 x2 : 2b78ccbbff369100 [ 265.964487] x1 : 0000000000000000 x0 : ffff800054627000 [ 265.964491] Call trace: [ 265.964494] hclgevf_cmd_uninit+0xbc/0x300 [ 265.964496] hclgevf_uninit_ae_dev+0x9c/0xe8 [ 265.964501] hnae3_unregister_ae_dev+0xb0/0x130 [ 265.964516] hns3_remove+0x34/0x88 [hns3] [ 266.009683] pci_device_remove+0x48/0xf0 [ 266.009692] device_release_driver_internal+0x114/0x1e8 [ 266.030058] device_driver_detach+0x28/0x38 [ 266.034224] unbind_store+0xd4/0x108 [ 266.037784] drv_attr_store+0x40/0x58 [ 266.041435] sysfs_kf_write+0x54/0x80 [ 266.045081] kernfs_fop_write+0x12c/0x250 [ 266.049076] vfs_write+0xc4/0x248 [ 266.052378] ksys_write+0x74/0xf8 [ 266.055677] __arm64_sys_write+0x24/0x30 [ 266.059584] el0_svc_common.constprop.3+0x84/0x270 [ 266.064354] do_el0_svc+0x34/0xa0 [ 266.067658] el0_svc+0x38/0x40 [ 266.070700] el0_sync_handler+0x8c/0xb0 [ 266.074519] el0_sync+0x140/0x180 It looks like the BAR memory region had already been unmapped before we start clearing CMDQ registers in it, which is pretty bad and the kernel happily kills itself because of a Current EL Data Abort (on arm64). Moving the CMDQ uninitialization a bit early fixes the issue for me. Fixes: 862d969a ("net: hns3: do VF's pci re-initialization while PF doing FLR") Signed-off-by: NZenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20201023051550.793-1-yuzenghui@huawei.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 30 9月, 2020 1 次提交
-
-
由 Huazhong Tan 提交于
Add RoCE VF client reset support by notifying the RoCE VF client when hns3 VF is resetting and adding a interface to query whether CMDQ is ready to work. Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 28 9月, 2020 3 次提交
-
-
由 Guangbin Huang 提交于
The device specifications querying is unsupported by the old firmware, in this case, these specifications are 0. However, some specifications should not be 0 or will cause problem. So after querying from firmware, some device specifications are needed to check their value and set to default value if their values are 0. Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Guangbin Huang 提交于
To improve code maintainability and compatibility, new commands HCLGE_OPC_QUERY_DEV_SPECS for PF and HCLGEVF_OPC_QUERY_DEV_SPECS for VF are introduced to query device specifications, instead of statically defining specifications by checking the hardware version or other methods. Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Guangbin Huang 提交于
To better identify the device version, struct hnae3_handle adds a member dev_version to replace pci revision. The dev_version consists of hardware version and PCI revision. The hardware version is queried from firmware by an existing firmware version query command. Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 25 9月, 2020 2 次提交
-
-
由 Guangbin Huang 提交于
VF devices do not have speed division, its speed is depended on its PF. So macro name of PCI device id of VF is incorrent to have 100G info, it should be renamed by removing 100G info. Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Yufeng Mo 提交于
If a variable is assigned a value before it is used, it's no need to assign an initial value to the variable. So remove these redundant operations. Signed-off-by: NYufeng Mo <moyufeng@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 22 9月, 2020 1 次提交
-
-
由 Qinglang Miao 提交于
Signed-off-by: NQinglang Miao <miaoqinglang@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 09 9月, 2020 2 次提交
-
-
由 Guangbin Huang 提交于
When reset fails, if there are some pending jobs for the periodic service task, it does not do anything except print error each time the task is scheduled. So skip the periodic service task if reset failed. Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Huazhong Tan 提交于
Since variable send_msg and ret only used in if branch, so move their definition into the if branch. Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 07 8月, 2020 1 次提交
-
-
由 Colin Ian King 提交于
There is a spelling mistake in a dev_err message. Fix it. Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 29 7月, 2020 2 次提交
-
-
由 Guojia Liao 提交于
When device is resetting or reset failed, firmware is unable to handle mailbox. VLAN should not be configured in this case. Fixes: fe4144d4 ("net: hns3: sync VLAN filter entries when kill VLAN ID failed") Signed-off-by: NGuojia Liao <liaoguojia@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jian Shen 提交于
Currently hclgevf_update_port_base_vlan_info() may be called when VF is resetting, which may cause hns3_nic_net_open() being called twice unexpectedly. So fix it by adding a reset check for it, and extend critical region for rntl_lock in hclgevf_update_port_base_vlan_info(). Fixes: 92f11ea1 ("net: hns3: fix set port based VLAN issue for VF") 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>
-
- 07 7月, 2020 1 次提交
-
-
由 Huazhong Tan 提交于
When asserts VF reset fail, flag HCLGEVF_STATE_CMD_DISABLE and handshake status should not set, otherwise the retry will fail. So adds a check for asserting VF reset and returns directly when fails. Fixes: ef5f8e50 ("net: hns3: stop handling command queue while resetting VF") Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 31 5月, 2020 1 次提交
-
-
由 Huazhong Tan 提交于
Remove a redundant blank line in hclgevf_cmd_set_promisc_mode(), and fix a reverse xmas tree coding style issue in hclgevf_set_rss_tc_mode(). Reported-by: NJian Shen <shenjian15@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 29 5月, 2020 2 次提交
-
-
由 Huazhong Tan 提交于
HCLGEVF_CMDQ_INTR_SRC_REG and HCLGEVF_CMDQ_INTR_STS_REG are same as HCLGEVF_VECTOR0_CMDQ_SRC_REG and HCLGEVF_VECTOR0_CMDQ_STAT_REG, replace the former with the latter, and rename macro HCLGEVF_VECTOR0_CMDQ_STAT_REG since 'stat' is not abbreviation of 'state'. Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Huazhong Tan 提交于
Modify field .gro_en in struct hclgevf_cfg_gro_status_cmd to u8 according to the UM, otherwise, it will overwrite the reserved byte which may be used for other purpose. Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 28 5月, 2020 1 次提交
-
-
由 Guangbin Huang 提交于
To prevent from initializing VF NIC client in reset handling state, this patch adds resetting check in hclgevf_init_nic_client_instance(). Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 26 4月, 2020 3 次提交
-
-
由 Jian Shen 提交于
Currently, the PF driver removes all (including its VFs') MAC/VLAN flow director table entries when resetting, and restores them after reset completed. In fact, the hardware will clear all table entries only in IMP reset and global reset. So driver only needs to restore the table entries in these cases, and needs do nothing when PF reset, FLR or other function level reset. This patch optimizes it by removing unnecessary table entries clear and restoring handling in the reset flow, and doing the restoring after reset completed. 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>
-
由 Jian Shen 提交于
As the HNS3 driver doesn't update the MAC address directly in function hns3_set_rx_mode() now, it can't know whether the MAC table is full from __dev_uc_sync() and __dev_mc_sync(), so it's senseless to handle the overflow promisc here. This patch removes the handle of overflow promisc from function hns3_set_rx_mode(), and updates the promisc mode in the service task. 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>
-
由 Jian Shen 提交于
Currently, the HNS3 driver sync and unsync MAC address in function hns3_set_rx_mode(). For PF, it adds and deletes MAC address directly in the path of dev_set_rx_mode(). If failed, it won't retry until next calling of hns3_set_rx_mode(). On the other hand, if request add and remove a same address many times at a short interval, each request must be done one by one, can't be merged. For VF, it sends mailbox messages to PF to request adding or deleting MAC address in the path of function hns3_set_rx_mode(), no matter the address is configured success. This patch refines it by recording the MAC address in function hns3_set_rx_mode(), and updating MAC address in the service task. If failed, it will retry by the next calling of periodical service task. It also uses some state to mark the state of each MAC address in the MAC list, which can help merge configure request for a same address. With these changes, when global reset or IMP reset occurs, we can restore the MAC table with the MAC list. 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>
-
- 31 3月, 2020 2 次提交
-
-
由 Guojia Liao 提交于
Currently, VF's RSS configuration would be set to default after VF reset, the the user's one will loss. To fix it, this patch separates hclgevf_rss_init_hw() into two parts, one sets up the default RSS configuration and just be called when driver loading, one configures the hardware and be called by driver loading or reset. Fixes: d97b3072 ("net: hns3: Add RSS tuples support for VF") Signed-off-by: NGuojia Liao <liaoguojia@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Yunsheng Lin 提交于
The WQ in hns3 driver is allocated with WQ_MEM_RECLAIM flag in order to guarantee forward progress, which may cause hns3' WQ_MEM_RECLAIM WQ flushing infiniband' !WQ_MEM_RECLAIM WQ warning: [11246.200168] hns3 0000:bd:00.1: Reset done, hclge driver initialization finished. [11246.209979] hns3 0000:bd:00.1 eth7: net open [11246.227608] ------------[ cut here ]------------ [11246.237370] workqueue: WQ_MEM_RECLAIM hclge:hclge_service_task [hclge] is flushing !WQ_MEM_RECLAIM infiniband:0x0 [11246.237391] WARNING: CPU: 50 PID: 2279 at ./kernel/workqueue.c:2605 check_flush_dependency+0xcc/0x140 [11246.260412] Modules linked in: hclgevf hns_roce_hw_v2 rdma_test(O) hns3 xt_CHECKSUM iptable_mangle xt_conntrack ipt_REJECT nf_reject_ipv4 ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter bpfilter vfio_iommu_type1 vfio_pci vfio_virqfd vfio ib_isert iscsi_target_mod ib_ipoib ib_umad rpcrdma ib_iser libiscsi scsi_transport_iscsi aes_ce_blk crypto_simd cryptd aes_ce_cipher sunrpc nls_iso8859_1 crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce joydev input_leds hid_generic usbkbd usbmouse sbsa_gwdt usbhid usb_storage hid ses hclge hisi_zip hisi_hpre hisi_sec2 hnae3 hisi_qm ahci hisi_trng_v2 evbug uacce rng_core gpio_dwapb autofs4 hisi_sas_v3_hw megaraid_sas hisi_sas_main libsas scsi_transport_sas [last unloaded: hns_roce_hw_v2] [11246.325742] CPU: 50 PID: 2279 Comm: kworker/50:0 Kdump: loaded Tainted: G O 5.4.0-rc4+ #1 [11246.335181] Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDD, BIOS 2280-V2 CS V3.B140.01 12/18/2019 [11246.344802] Workqueue: hclge hclge_service_task [hclge] [11246.350007] pstate: 60c00009 (nZCv daif +PAN +UAO) [11246.354779] pc : check_flush_dependency+0xcc/0x140 [11246.359549] lr : check_flush_dependency+0xcc/0x140 [11246.364317] sp : ffff800268a73990 [11246.367618] x29: ffff800268a73990 x28: 0000000000000001 [11246.372907] x27: ffffcbe4f5868000 x26: ffffcbe4f5541000 [11246.378196] x25: 00000000000000b8 x24: ffff002fdd0ff868 [11246.383483] x23: ffff002fdd0ff800 x22: ffff2027401ba600 [11246.388770] x21: 0000000000000000 x20: ffff002fdd0ff800 [11246.394059] x19: ffff202719293b00 x18: ffffcbe4f5541948 [11246.399347] x17: 000000006f8ad8dd x16: 0000000000000002 [11246.404634] x15: ffff8002e8a734f7 x14: 6c66207369205d65 [11246.409922] x13: 676c63685b206b73 x12: 61745f6563697672 [11246.415208] x11: 65735f65676c6368 x10: 3a65676c6368204d [11246.420494] x9 : 49414c4345525f4d x8 : 6e6162696e69666e [11246.425782] x7 : 69204d49414c4345 x6 : ffffcbe4f5765145 [11246.431068] x5 : 0000000000000000 x4 : 0000000000000000 [11246.436355] x3 : 0000000000000030 x2 : 00000000ffffffff [11246.441642] x1 : 3349eb1ac5310100 x0 : 0000000000000000 [11246.446928] Call trace: [11246.449363] check_flush_dependency+0xcc/0x140 [11246.453785] flush_workqueue+0x110/0x410 [11246.457691] ib_cache_cleanup_one+0x54/0x468 [11246.461943] __ib_unregister_device+0x70/0xa8 [11246.466279] ib_unregister_device+0x2c/0x40 [11246.470455] hns_roce_exit+0x34/0x198 [hns_roce_hw_v2] [11246.475571] __hns_roce_hw_v2_uninit_instance.isra.56+0x3c/0x58 [hns_roce_hw_v2] [11246.482934] hns_roce_hw_v2_reset_notify+0xd8/0x210 [hns_roce_hw_v2] [11246.489261] hclge_notify_roce_client+0x84/0xe0 [hclge] [11246.494464] hclge_reset_rebuild+0x60/0x730 [hclge] [11246.499320] hclge_reset_service_task+0x400/0x5a0 [hclge] [11246.504695] hclge_service_task+0x54/0x698 [hclge] [11246.509464] process_one_work+0x15c/0x458 [11246.513454] worker_thread+0x144/0x520 [11246.517186] kthread+0xfc/0x128 [11246.520314] ret_from_fork+0x10/0x18 [11246.523873] ---[ end trace eb980723699c2585 ]--- [11246.528710] hns3 0000:bd:00.2: Func clear success after reset. [11246.528747] hns3 0000:bd:00.0: Func clear success after reset. [11246.907710] hns3 0000:bd:00.1 eth7: link up According to [1] and [2]: There seems to be no specific guidance about how to handling the forward progress guarantee of network device's WQ yet, and other network device's WQ seem to be marked with WQ_MEM_RECLAIM without a clear reason. So this patch removes the WQ_MEM_RECLAIM flag when allocating WQ to aviod the above warning. 1. https://www.spinics.net/lists/netdev/msg631646.html 2. https://www.spinics.net/lists/netdev/msg632097.html Fixes: 0ea68902 ("net: hns3: allocate WQ with WQ_MEM_RECLAIM flag") Signed-off-by: NYunsheng Lin <linyunsheng@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 22 3月, 2020 1 次提交
-
-
由 Yufeng Mo 提交于
For making the code more readable, this adds several new structure to replace the msg field in structure hclge_mbx_vf_to_pf_cmd and hclge_mbx_pf_to_vf_cmd. Also uses macro to instead of some magic number. Signed-off-by: NYufeng Mo <moyufeng@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 13 3月, 2020 1 次提交
-
-
由 Jian Shen 提交于
Currently, if VF is loaded on the host side, the host doesn't clear the VF's VLAN table entries when VF removing. In this case, when doing reset and disabling sriov at the same time the VLAN device over VF will be removed, but the VLAN table entries in hardware are remained. This patch fixes it by asking PF to clear the VLAN table entries for VF when VF is removing. It also clears the VLAN table full bit after VF VLAN table entries being cleared. Fixes: c6075b19 ("net: hns3: Record VF vlan tables") 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>
-
- 10 3月, 2020 1 次提交
-
-
由 Huazhong Tan 提交于
When received an unknown vector 0 interrupt, there is not a helpful information for user to realize that now. So this patch prints out the value of the status register for this case, and uses dev_info() instead of dev_dbg() in hclge_check_event_cause(). Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 21 1月, 2020 3 次提交
-
-
由 Huazhong Tan 提交于
This patch removes some unnecessary return value assignments, some duplicated printing in the caller, refines the judgment of 0 and uses le16_to_cpu to replace __le16_to_cpu. Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Guangbin Huang 提交于
This patch deletes some unnecessary blank lines and spaces to clean up code, and in hclgevf_set_vlan_filter() moves the comment to the front of hclgevf_send_mbx_msg(). Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Huazhong Tan 提交于
reset_type means what kind of reset the driver is handling now, so after initializing or reset, the reset_type of VF should be set to HNAE3_NONE_RESET, otherwise, this unknown default value may be a little misleading when the device is running. Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 12 1月, 2020 2 次提交
-
-
由 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>
-
由 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>
-
- 07 1月, 2020 1 次提交
-
-
由 Yonglong Liu 提交于
The misc IRQ of all the devices have the same name, so it's hard to find the right misc IRQ of the device. This patch modifies the misc IRQ names as "hclge/hclgevf"-misc- "pci name". And now the IRQ name is not related to net device name anymore, so change the HNAE3_INT_NAME_LEN to 32 bytes, and that is enough. Signed-off-by: NYonglong Liu <liuyonglong@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 17 12月, 2019 4 次提交
-
-
由 Guojia Liao 提交于
service_task will be scheduled per second to do some periodic jobs. When reset fails, it means this device is not available now, so the periodic jobs do not need to be handled. This patch adds flag HCLGE_STATE_RST_FAIL/HCLGEVF_STATE_RST_FAIL to indicate that reset fails, and checks this flag before schedule periodic task. Signed-off-by: NGuojia Liao <liaoguojia@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Yunsheng Lin 提交于
The hns3 driver may be used in memory reclaim path when it is the low level transport of a network file system, so it needs to guarantee forward progress even under memory pressure. This patch allocates a private WQ with WQ_MEM_RECLAIM set for both hclge_main and hclgevf_main modules. Signed-off-by: NYunsheng Lin <linyunsheng@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Yunsheng Lin 提交于
There are four work (mbx_service_task, service_task, rst_service_task and keep_alive_task)in the hclgevf module, mbx_service_task is for handling mailbox issue, service_task is for periodic management issue and rst_service_task is for reset related issue, keep_alive_task is used to keepalive between PF and VF, which can be done in a single work. This patch removes the mbx_service_task, rst_service_task and keep_alive_task, and moves the related handling to the service_task work in order to remove concurrency between the four work and to improve efficiency. Signed-off-by: NYunsheng Lin <linyunsheng@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Yunsheng Lin 提交于
Currently, a timer is defined to schedule hclgevf_service per second. To simplify the code, this patch uses the delayed work instead of timer to schedule hclgevf_serive. Signed-off-by: NYunsheng Lin <linyunsheng@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 01 11月, 2019 2 次提交
-
-
由 Guojia Liao 提交于
Using '%d' for printing type unsigned int or '%u' for type int would cause static tools to give false warnings, so this patch cleanups this warning by using the suitable format specifier of the type of variable. BTW, modifies the type of some variables and macro to synchronize with their usage. Signed-off-by: NGuojia Liao <liaoguojia@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Guangbin Huang 提交于
To unify code style and make code simpler, this patch modifies some code, deletes unnecessary blank lines and {}, changes location of code, and so on. No functional change. Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-