- 27 Jun, 2019 14 commits
-
-
Julian Wiedmann authored
De-duplicate the pm callback implementations from the two sub-drivers, replacing them with core helpers that delegate to the .set_online and .set_offline callbacks. Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Julian Wiedmann authored
Apply some cleanups to qeth_snmp_command() and its callback: 1. when accessing the user data, use the proper struct instead of hard-coded offsets. Also copy the request data straight into the allocated cmd, skipping the extra memdup_user() to a tmp buffer. 2. capping the request length is no longer needed, the same check gets applied at a base level in qeth_alloc_cmd(). 3. clean up some duplicated (and misindented) trace statements. Signed-off-by:
-
Julian Wiedmann authored
Now that all cmds are dynamically allocated, the code for static cmd buffers can go away entirely. Resulting in a nice reduction of code/data size & complexity, while removing the risk that qeth_clear_cmd_buffers() releases cmds that are still in-flight. Signed-off-by:
-
Julian Wiedmann authored
The base MPC cmds are the last remaining user of the static cmd buffers. Port them over to use dynamic allocation, and stop backing the write channel's cmd buffers with pages. Signed-off-by:
-
Julian Wiedmann authored
The VNICC code is somewhat quirky in that it defers the whole cmd setup to a common helper qeth_l2_vnicc_request(). Some of the cmd specifics are then passed in via parameter, while others are simply hard-coded. Split the whole machinery up into the usual format: one helper that allocates the cmd & fills in the common fields, while all the cmd originators take care of their sub-cmd type specific work. This makes it much easier to calculate the cmd's precise length, and reduces code complexity. Signed-off-by:
Alexandra Winter <wintera@linux.ibm.com> Signed-off-by:
-
Julian Wiedmann authored
Add a new wrapper that allocates DIAG cmds of the right size, and fills in the common fields. Signed-off-by:
-
Julian Wiedmann authored
This patch converts the adapter, assist and bridgeport cmd paths to dynamic allocation. Most of the work is about re-organizing the cmd headers, calculating the correct cmd length, and filling in the right value in the sub-cmd's length field. Since we now also set the correct length for cmds that are not reflected by a fixed struct (ie SNMP), we can remove the work-around from qeth_snmp_command(). Signed-off-by:
-
Julian Wiedmann authored
For code that uses qeth_send_simple_setassparms_prot(), we currently can't differentiate whether the cmd should contain (1) no parameter, or (2) a 4-byte parameter with value 0. At the moment this doesn't cause any trouble. But when using dynamically allocated cmds, we need to know whether to allocate & transmit an additional 4 bytes of zeroes. So instead of the raw parameter value, pass a parameter pointer (or NULL) to qeth_send_simple_setassparms_prot(). Signed-off-by:
-
Julian Wiedmann authored
This patch reduces the usage of the write channel's static cmd buffers, by dynamically allocating all simple IPA cmds (eg. STARTLAN, SETVMAC). It also converts the OSN path. Doing so requires some changes to how we calculate the cmd length. Currently when building IPA cmds, we're quite generous in how much data we send down to the device (basically the size of the biggest cmd we know). This is no real concern at the moment, since the static cmd buffers are backed with zeroed pages. But for dynamic allocations, the exact length matters. So this patch also adds the needed length calculations to each cmd path. Commands that have multiple subtypes (eg. SETADP) of differing length will be converted with follow-up patches. Signed-off-by:
-
Ursula Braun authored
There are common steps when releasing an accepted or unaccepted socket. Move this code into a common routine. Signed-off-by:
Ursula Braun <ubraun@linux.ibm.com> Signed-off-by:
Karsten Graul <kgraul@linux.ibm.com> Signed-off-by:
-
David S. Miller authored
Florian Westphal says: ==================== net: ipv4: fix circular-list infinite loop Tariq and Ran reported a regression caused by net-next commit 2638eb8b ("net: ipv4: provide __rcu annotation for ifa_list"). This happens when net.ipv4.conf.$dev.promote_secondaries sysctl is enabled -- we can arrange for ifa->next to point at ifa, so next process that tries to walk the list loops forever. Fix this and extend rtnetlink.sh with a small test case for this. ==================== Signed-off-by:
-
Florian Westphal authored
This exercises the 'promote_secondaries' code path. Without previous fix, this triggers infinite loop/soft lockup: ifconfig process spinning at 100%, never to return. Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
Florian Westphal authored
secondary address promotion causes infinite loop -- it arranges for ifa->ifa_next to point back to itself. Problem is that 'prev_prom' and 'last_prim' might point at the same entry, so 'last_sec' pointer must be obtained after prev_prom->next update. Fixes: 2638eb8b ("net: ipv4: provide __rcu annotation for ifa_list") Reported-by:
Ran Rozenstein <ranro@mellanox.com> Reported-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
-
Maxime Chevallier authored
When parsing an ethtool_rx_flow_spec, users can specify an ethernet flow which could contain matches based on the ethernet header, such as the MAC address, the VLAN tag or the ethertype. ETHER_FLOW uses the src and dst ethernet addresses, along with the ethertype as keys. Matches based on the vlan tag are also possible, but they are specified using the special FLOW_EXT flag. Signed-off-by:
Maxime Chevallier <maxime.chevallier@bootlin.com> Acked-by:
Pablo Neira Ayuso <pablo@gnumonks.org> Signed-off-by:
-
- 26 Jun, 2019 26 commits
-
-
David S. Miller authored
Palmer Dabbelt says: ==================== net: macb: Fix compilation on systems without COMMON_CLK, v2 Our patch to add support for the FU540-C000 broke compilation on at least powerpc allyesconfig, which was found as part of the linux-next build regression tests. This must have somehow slipped through the cracks, as the patch has been reverted in linux-next for a while now. This patch applies on top of the offending commit, which is the only one I've even tried it on as I'm not sure how this subsystem makes it to Linus. This patch set fixes the issue by adding a dependency of COMMON_CLK to the MACB Kconfig entry, which avoids the build failure by disabling MACB on systems where it wouldn't compile. All known users of MACB have COMMON_CLK, so this shouldn't cause any issues. This is a significantly simpler approach than disabling just the FU540-C000 support. I've also included a second patch to indicate this is a driver for a Cadence device that was originally written by an engineer at Atmel. The only relation is that I stumbled across it when writing the first patch. Changes since v1 <20190624061603.1704-1-palmer@sifive.com>: * Disable MACB on systems without COMMON_CLK, instead of just disabling the FU540-C000 support on these systems. * Update the commit message to reflect the driver was written by Atmel. ==================== Signed-off-by: -
Palmer Dabbelt authored
The help text makes it look like NET_VENDOR_CADENCE enables support for Atmel devices, when in reality it's a driver written by Atmel that supports Cadence devices. This may confuse users that have this device on a non-Atmel SoC. The fix is just s/Atmel/Cadence/, but I did go and re-wrap the Kconfig help text as that change caused it to go over 80 characters. Signed-off-by:
Palmer Dabbelt <palmer@sifive.com> Acked-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
-
Palmer Dabbelt authored
commit c218ad55 ("macb: Add support for SiFive FU540-C000") added a dependency on the common clock framework to the macb driver, but didn't express that dependency in Kconfig. As a result macb now fails to compile on systems without COMMON_CLK, which specifically causes a build failure on powerpc allyesconfig. This patch adds the dependency, which results in the macb driver no longer being selectable on systems without the common clock framework. All known systems that have this device already support the common clock framework, so this should not cause trouble for any uses. Supporting both the FU540-C000 and systems without COMMON_CLK is quite ugly. I've build tested this on powerpc allyesconfig and RISC-V defconfig (which selects MACB), but I have not even booted the resulting kernels. Fixes: c218ad55 ("macb: Add support for SiFive FU540-C000") Signed-off-by:
-
Dave Taht authored
The longstanding prohibition against using 0.0.0.0/8 dates back to two issues with the early internet. There was an interoperability problem with BSD 4.2 in 1984, fixed in BSD 4.3 in 1986. BSD 4.2 has long since been retired. Secondly, addresses of the form 0.x.y.z were initially defined only as a source address in an ICMP datagram, indicating "node number x.y.z on this IPv4 network", by nodes that know their address on their local network, but do not yet know their network prefix, in RFC0792 (page 19). This usage of 0.x.y.z was later repealed in RFC1122 (section 3.2.2.7), because the original ICMP-based mechanism for learning the network prefix was unworkable on many networks such as Ethernet (which have longer addresses that would not fit into the 24 "node number" bits). Modern networks use reverse ARP (RFC0903) or BOOTP (RFC0951) or DHCP (RFC2131) to find their full 32-bit address and CIDR netmask (and other parameters such as default gateways). 0.x.y.z has had 16,777,215 addresses in 0.0.0.0/8 space left unused and reserved for future use, since 1989. This patch allows for these 16m new IPv4 addresses to appear within a box or on the wire. Layer 2 switches don't care. 0.0.0.0/32 is still prohibited, of course. Signed-off-by:
Dave Taht <dave.taht@gmail.com> Signed-off-by:
John Gilmore <gnu@toad.com> Acked-by:
Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by:
-
David Ahern authored
dst_default_metrics has all of the metrics initialized to 0, so nothing will be added to the skb in rtnetlink_put_metrics. Avoid the loop if metrics is from dst_default_metrics. Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
David S. Miller authored
Puranjay Mohan says: ==================== net: fddi: skfp: Use PCI generic definitions instead of private duplicates This patch series removes the private duplicates of PCI definitions in favour of generic definitions defined in pci_regs.h. This driver only uses some of the generic PCI definitons, which are included from pci_regs.h and thier private versions are removed from skfbi.h with all other private defines. The skfbi.h defines PCI_REV_ID and other private defines with different names, these are renamed to Generic PCI names to make them compatible with defines in pci_regs.h. All unused defines are removed from skfbi.h. Changes in v5: Removed unused PCI definitions which were left in v4 Changes in v4: Removed unused PCI definitions which were left in v3 Changes in v3: Renamed all local PCI definitions to Generic names. Corrected coding style mistakes. Changes in v2: Converted individual patches to a series. Made sure that individual patches build correctly ==================== Signed-off-by: -
Puranjay Mohan authored
Remove unused private PCI definitions from skfbi.h because generic PCI symbols are already included from pci_regs.h. Signed-off-by:
Puranjay Mohan <puranjay12@gmail.com> Signed-off-by:
-
Puranjay Mohan authored
Include the uapi/linux/pci_regs.h header file which contains the generic PCI defines. Signed-off-by:
-
Puranjay Mohan authored
Rename the PCI_REV_ID and other local defines to Generic PCI define names in skfbi.h and drvfbi.c to make it compatible with the pci_regs.h. Signed-off-by:
-
David S. Miller authored
Merge tag 'wireless-drivers-next-for-davem-2019-06-26' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valu says: ==================== wireless-drivers-next patches for 5.3 First set of patches for 5.3, but not that many patches this time. This pull request fails to compile with the tip tree due to ktime_get_boot_ns() API changes there. It should be easy for Linus to fix it in p54 driver once he pulls this, an example resolution here: https://lkml.kernel.org/r/20190625160432.533aa140@canb.auug.org.au Major changes: airo * switch to use skcipher interface p54 * support boottime in scan results rtw88 * add fast xmit support * add random mac address on scan support rt2x00 * add software watchdog to detect hangs, it's disabled by default ==================== Signed-off-by:
-
Jon Hunter authored
If the PHY does not support EEE mode, then a crash is observed when the ethernet interface is enabled. The crash occurs, because if the PHY does not support EEE, then although the EEE timer is never configured, it is still marked as enabled and so the stmmac ethernet driver is still trying to update the timer by calling mod_timer(). This triggers a BUG() in the mod_timer() because we are trying to update a timer when there is no callback function set because timer_setup() was never called for this timer. The problem is caused because we return true from the function stmmac_eee_init(), marking the EEE timer as enabled, even when we have not configured the EEE timer. Fix this by ensuring that we return false if the PHY does not support EEE and hence, 'eee_active' is not set. Fixes: 74371272 ("net: stmmac: Convert to phylink and remove phylib logic") Signed-off-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Jon Hunter authored
When stmmac_eee_init() is called to disable EEE support, then the timer for EEE support is stopped and we return from the function. Prior to stopping the timer, a mutex was acquired but in this case it is never released and so could cause a deadlock. Fix this by releasing the mutex prior to returning from stmmax_eee_init() when stopping the EEE timer. Fixes: 74371272 ("net: stmmac: Convert to phylink and remove phylib logic") Signed-off-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Eric Dumazet authored
syzbot reminded us that rt6_nh_dump_exceptions() needs to be called with rcu_read_lock() net/ipv6/route.c:1593 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by syz-executor609/8966: #0: 00000000b7dbe288 (rtnl_mutex){+.+.}, at: netlink_dump+0xe7/0xfb0 net/netlink/af_netlink.c:2199 #1: 00000000f2d87c21 (&(&tb->tb6_lock)->rlock){+...}, at: spin_lock_bh include/linux/spinlock.h:343 [inline] #1: 00000000f2d87c21 (&(&tb->tb6_lock)->rlock){+...}, at: fib6_dump_table.isra.0+0x37e/0x570 net/ipv6/ip6_fib.c:533 stack backtrace: CPU: 0 PID: 8966 Comm: syz-executor609 Not tainted 5.2.0-rc5+ #43 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 lockdep_rcu_suspicious+0x153/0x15d kernel/locking/lockdep.c:5250 fib6_nh_get_excptn_bucket+0x18e/0x1b0 net/ipv6/route.c:1593 rt6_nh_dump_exceptions+0x45/0x4d0 net/ipv6/route.c:5541 rt6_dump_route+0x904/0xc50 net/ipv6/route.c:5640 fib6_dump_node+0x168/0x280 net/ipv6/ip6_fib.c:467 fib6_walk_continue+0x4a9/0x8e0 net/ipv6/ip6_fib.c:1986 fib6_walk+0x9d/0x100 net/ipv6/ip6_fib.c:2034 fib6_dump_table.isra.0+0x38a/0x570 net/ipv6/ip6_fib.c:534 inet6_dump_fib+0x93c/0xb00 net/ipv6/ip6_fib.c:624 rtnl_dump_all+0x295/0x490 net/core/rtnetlink.c:3445 netlink_dump+0x558/0xfb0 net/netlink/af_netlink.c:2244 __netlink_dump_start+0x5b1/0x7d0 net/netlink/af_netlink.c:2352 netlink_dump_start include/linux/netlink.h:226 [inline] rtnetlink_rcv_msg+0x73d/0xb00 net/core/rtnetlink.c:5182 netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477 rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5237 netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328 netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:646 [inline] sock_sendmsg+0xd7/0x130 net/socket.c:665 sock_write_iter+0x27c/0x3e0 net/socket.c:994 call_write_iter include/linux/fs.h:1872 [inline] new_sync_write+0x4d3/0x770 fs/read_write.c:483 __vfs_write+0xe1/0x110 fs/read_write.c:496 vfs_write+0x20c/0x580 fs/read_write.c:558 ksys_write+0x14f/0x290 fs/read_write.c:611 __do_sys_write fs/read_write.c:623 [inline] __se_sys_write fs/read_write.c:620 [inline] __x64_sys_write+0x73/0xb0 fs/read_write.c:620 do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4401b9 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffc8e134978 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004401b9 RDX: 000000000000001c RSI: 0000000020000000 RDI: 00 Fixes: 1e47b483 ("ipv6: Dump route exceptions if requested") Signed-off-by:Eric Dumazet <edumazet@google.com> Cc: Stefano Brivio <sbrivio@redhat.com> Cc: David Ahern <dsahern@gmail.com> Reviewed-by:
Stefano Brivio <sbrivio@redhat.com> Signed-off-by:
-
Eric Dumazet authored
sysbot reported that we lack appropriate rcu_read_lock() protection in fib_dump_info_fnhe() net/ipv4/route.c:2875 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by syz-executor609/8966: #0: 00000000b7dbe288 (rtnl_mutex){+.+.}, at: netlink_dump+0xe7/0xfb0 net/netlink/af_netlink.c:2199 stack backtrace: CPU: 0 PID: 8966 Comm: syz-executor609 Not tainted 5.2.0-rc5+ #43 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 lockdep_rcu_suspicious+0x153/0x15d kernel/locking/lockdep.c:5250 fib_dump_info_fnhe+0x9d9/0x1080 net/ipv4/route.c:2875 fn_trie_dump_leaf net/ipv4/fib_trie.c:2141 [inline] fib_table_dump+0x64a/0xd00 net/ipv4/fib_trie.c:2175 inet_dump_fib+0x83c/0xa90 net/ipv4/fib_frontend.c:1004 rtnl_dump_all+0x295/0x490 net/core/rtnetlink.c:3445 netlink_dump+0x558/0xfb0 net/netlink/af_netlink.c:2244 __netlink_dump_start+0x5b1/0x7d0 net/netlink/af_netlink.c:2352 netlink_dump_start include/linux/netlink.h:226 [inline] rtnetlink_rcv_msg+0x73d/0xb00 net/core/rtnetlink.c:5182 netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477 rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5237 netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328 netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:646 [inline] sock_sendmsg+0xd7/0x130 net/socket.c:665 sock_write_iter+0x27c/0x3e0 net/socket.c:994 call_write_iter include/linux/fs.h:1872 [inline] new_sync_write+0x4d3/0x770 fs/read_write.c:483 __vfs_write+0xe1/0x110 fs/read_write.c:496 vfs_write+0x20c/0x580 fs/read_write.c:558 ksys_write+0x14f/0x290 fs/read_write.c:611 __do_sys_write fs/read_write.c:623 [inline] __se_sys_write fs/read_write.c:620 [inline] __x64_sys_write+0x73/0xb0 fs/read_write.c:620 do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4401b9 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffc8e134978 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004401b9 RDX: 000000000000001c RSI: 0000000020000000 RDI: 0000000000000003 RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8 R10: 0000000000000010 R11: 0000000000000246 R12: 0000000000401a40 R13: 0000000000401ad0 R14: 0000000000000000 R15: 0000000000000000 Fixes: ee28906f ("ipv4: Dump route exceptions if requested") Signed-off-by:syzbot <syzkaller@googlegroups.com> Reviewed-by:
-
Jakub Kicinski authored
This reverts commit 315c28d2 ("net: ena: ethtool: add extra properties retrieval via get_priv_flags"). As discussed at netconf and on the mailing list we can't allow for the the abuse of private flags for exposing arbitrary device labels. Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
-
David S. Miller authored
Huazhong Tan says: ==================== net: hns3: some code optimizations & bugfixes This patch-set includes code optimizations and bugfixes for the HNS3 ethernet controller driver. [patch 1/11] fixes a selftest issue when doing autoneg. [patch 2/11 - 3-11] adds two code optimizations about VLAN issue. [patch 4/11] restores the MAC autoneg state after reset. [patch 5/11 - 8/11] adds some code optimizations and bugfixes about HW errors handling. [patch 9/11 - 11/11] fixes some issues related to driver loading and unloading. ==================== Signed-off-by: -
Weihang Li authored
If we failed to enable NIC HW error interrupts during client initialization in some cases, we should do exception handling to clear flags and free the resources. Fixes: 00ea6e5f ("net: hns3: delay and separate enabling of NIC and ROCE HW errors") Signed-off-by:
Weihang Li <liweihang@hisilicon.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Huazhong Tan authored
The ROCE HW errors should only be enabled when initializing ROCE's client, the current code enable it no matter initializing NIC or ROCE client. So this patch fixes it. Fixes: 00ea6e5f ("net: hns3: delay and separate enabling of NIC and ROCE HW errors") Signed-off-by:
-
Huazhong Tan authored
When loading or unloading module, it should wait for the reset task done before it un-initializes the client, otherwise the reset task may cause a NULL pointer reference. Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
-
Weihang Li authored
This patch adds check to number of bds before we allocate memory for them. If we get an invalid bd num in some cases, it will cause a memory overflow. Signed-off-by:
-
Weihang Li authored
We add override_pci_need_reset to prevent redundant and unwanted PF resets if a RAS error occurs in commit 69b51bbb ("net: hns3: fix to stop multiple HNS reset due to the AER changes"). Now in HNS3 driver, we use hw_err_reset_req to record reset level that we need to recover from a RAS error. This variable cans solve above issue as override_pci_need_reset, so this patch removes override_pci_need_reset. Signed-off-by:
-
Weihang Li authored
Users should be informed if HNS driver failed to allocate memory for descriptor when handling hw errors. This patch solve above issues. Signed-off-by:
-
Weihang Li authored
This patch optimizes hclge_handle_hw_ras_error() to make the code logic clearer. 1. If there was no NIC or Roce RAS when we read HCLGE_RAS_PF_OTHER_INT_STS_REG, we return directly. 2. Because NIC and Roce RAS may occurs at the same time, so we should check value of revision at first before we handle Roce RAS instead of only checking it in branch of no NIC RAS is detected. 3. Check HCLGE_STATE_RST_HANDLING each time before we want to return PCI_ERS_RESULT_NEED_RESET. 4. Remove checking of HCLGE_RAS_REG_NFE_MASK and HCLGE_RAS_REG_ROCEE_ERR_MASK because if hw_err_reset_req is not zero, it proves that we have set it in handling of NIC or Roce RAS. Signed-off-by:
-
Jian Shen authored
When doing global reset, the MAC autoneg state of fibre port is set to default, which may cause user configuration lost. This patch fixes it by restore the MAC autoneg state after reset. Fixes: 22f48e24 ("net: hns3: add autoneg and change speed support for fibre port") Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
-
Jian Shen authored
When HW is resetting, firmware is unable to handle commands from driver. So if remove VLAN device from stack at this time, it will fail to remove the VLAN ID from HW VLAN filter, then the VLAN filter status is unsynced with stack. This patch fixes it by recording the VLAN ID delete failed, and removes them again when reset complete. Fixes: 44e626f7 ("net: hns3: fix VLAN offload handle for VLAN inserted by port") Signed-off-by:
-
Jian Shen authored
For VF VLAN filter is disabled when VF VLAN table is full, then the new VLAN ID won't be added into VF VLAN table, it will always print fail log when remove these VLAN IDs. If user has added too many VLANs, it will cause massive verbose print logs. Signed-off-by:
-
