- 29 Jun, 2019 7 commits
-
-
Shahar S Matityahu authored
Use a different barker for ini dump to allow differentiation from legacy dump. Also it allows to remove INI_BIT from dump TLVs. Signed-off-by:
Shahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com>
-
Shahar S Matityahu authored
When a dump trigger is fired, the driver sets IWL_FWRT_STATUS_DUMPING and aborts any consecutive dump collection. To allow consecutive triggers firing, use 5 dump workers and allocate them upon incoming dump collection requests. This functionality is needed since in ini debug mode each trigger may have entirely different memory regions to collect unlike the legacy mode in which all the triggers dump the same memory regions. Signed-off-by:
-
Shahar S Matityahu authored
Allows to abort region collection in case the region size is 0. It is needed for future regions that their size might be 0. Signed-off-by:
-
Johannes Berg authored
Update the CSI API to the new version supported by the firmware. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Shahar S Matityahu authored
Unite dump memory ranges under a single struct and add a specific header for each type of memory. Also, maintain a single version to all dump structures. This cleanup is also needed for the future addition of FW notification regions and others. Signed-off-by:
-
Shahar S Matityahu authored
Improve the robustness of the dump collection flow in case of an early error: 1. in iwl_trans_pcie_sync_nmi, disable and enable interrupts only if they were already enabled 2. attempt to initiate dump collection in iwl_fw_dbg_error_collect only if the device is enabled 3. check Tx command queue was already allocated before trying to collect it Signed-off-by:
-
Jiri Kosina authored
As iwl_mvm_tx_mpdu() is not disabling BH while obtaining iwl_mvm_sta->lock (which is being taken from BH context as well), it has to be always invoked with BH disabled. Make that clear in a comment. Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
- 27 Jun, 2019 16 commits
-
-
Zong-Zhe Yang authored
Add a structure for power parameters including base, offset, limit and a function to get tx power parameters. Then, refine flow to get tx power index through the function. Signed-off-by:
Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by:
Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org>
-
Tzu-En Huang authored
Since this macro definition has different values in different chipset, the current defined macro value is for 8822b. This will cause the settings of 8822c be incorrect. Remove RTW_MAX_POWER_INDEX and use max_power_index in struct rtw_chip_info to make sure the value of different chipset is right. Signed-off-by:
Tzu-En Huang <tehuang@realtek.com> Signed-off-by:
-
Zong-Zhe Yang authored
Support more regulatory domains including IC, KCC, ACMA, CHILE, UKRAINE, and MEXICO. Corresponding tx power limits for these regulatory domains are added in tx power limit table. Besides, tx power limits in some case are also updated to follow RF v20 for better tx power indexes. Channel plan mapping table are upgraded to consider more 2G and 5G channel plans combination cases. It allow us to identify different situations more accuratly by channel plan IDs. In addition, mapping table for country code and channel plan ID and mapping table for country code and tx power limit are also updated to follow RF v20. It allow the new enrties in tx power limit table to be applied correctly. Signed-off-by:
-
Zong-Zhe Yang authored
If phy rate is decreased, sub bandwidth may be chosen by RA. We consider possible power limits and apply the min one; otherwise, the tx power index may be larger than spec. And we cross-reference power limits of vht and ht with 20/40M bandwidth in 5G to avoid values are not assigned. Signed-off-by:
-
Yan-Hsuan Chuang authored
When we are loading tx power limit from the power limit table, compare the world-wide limit with the current limit and choose the lowest power limit for the world-wide power settings. Signed-off-by:
-
Yan-Hsuan Chuang authored
Tx power limit is stored separately by 2G and 5G. But driver did not get tx power limit from 5G and causes incorrect tx power. Check if the channel is beyond 2G and get the corresponding tx power limit. Signed-off-by:
-
Yan-Hsuan Chuang authored
The orig variable is taken but not used, remove it Signed-off-by:
-
Yan-Hsuan Chuang authored
Rename the function names to make them have the same prefix "rtw_phy" for the tx power setting routines. Only the function names and corresponding identation are modified. Signed-off-by:
-
Yan-Hsuan Chuang authored
The type change from (void *) to (struct rtw_dev *) is redundant. Just pass the right type and compiler can check that for us. Signed-off-by:
-
Yan-Hsuan Chuang authored
Some functions that should be static are unnecessarily exposed, remove their declaration in header file phy.h. After resolving their declaration order, they can be declared as static. So this commit changes nothing except the order and marking them static. Signed-off-by:
-
Brian Norris authored
main_proc_lock and int_lock (in mwifiex_adapter) are the only spinlocks used in hardirq contexts. The rest are only in task or softirq contexts. Convert every other lock from *_irq{save,restore}() variants to _bh() variants. This is a mechanical transformation of all spinlock usage in mwifiex using the following: Step 1: I ran this nasty sed script: sed -i -E '/spin_lock_irqsave|spin_unlock_irqrestore/ { /main_proc_lock|int_lock/! { s:(spin_(un|)lock)_irq(save|restore):\1_bh: ; # Join broken lines. :a /;$/! { N; s/\s*\n\s*//; ba } /,.*\);$/ s:,.*\):\): } }' drivers/net/wireless/marvell/mwifiex/* Step 2: Manually delete the flags / ra_list_flags args from: mwifiex_send_single_packet() mwifiex_11n_aggregate_pkt() mwifiex_send_processed_packet() which are now unused. Step 3: Apply this semantic patch (coccinelle) to remove the unused 'flags' variables: // <smpl> @@ type T; identifier i; @@ ( extern T i; | - T i; ... when != i ) // </smpl> (Usage is something like this: make coccicheck COCCI=./patch.cocci MODE=patch M=drivers/net/wireless/marvell/mwifiex/ although this skips *.h files for some reasons, so I had to massage stuff.) Testing: I've played with a variety of stress tests, including download stress tests on the same APs which caught regressions with commit 5188d545 ("mwifiex: restructure rx_reorder_tbl_lock usage"). I've primarily tested on Marvell 8997 / PCIe, although I've given 8897 / SDIO a quick spin as well. Signed-off-by:Brian Norris <briannorris@chromium.org> Signed-off-by:
-
Brian Norris authored
mwifiex_11n_scan_and_dispatch() and mwifiex_11n_dispatch_pkt_until_start_win() share similar patterns, where they perform a few different actions on the same table, using the same lock, but non-atomically. There have been other attempts to clean up this sort of behavior, but they have had problems (incomplete; introducing new deadlocks). We can improve these functions' atomicity by queueing up our RX packets in a list, to dispatch at the end of the function. This avoids problems of another operation modifying the table in between our dispatch and rotation operations. This was inspired by investigations around this: http://lkml.kernel.org/linux-wireless/20181130175957.167031-1-briannorris@chromium.org Subject: [4.20 PATCH] Revert "mwifiex: restructure rx_reorder_tbl_lock usage" While the original (now-reverted) patch had good intentions in restructuring some of the locking patterns in this driver, it missed an important detail: we cannot defer to softirq contexts while already in an atomic context. We can help avoid this sort of problem by separating the two steps of: (1) iterating / clearing the mwifiex reordering table (2) dispatching received packets to upper layers This makes it much harder to make lock recursion mistakes, as these two steps no longer need to hold the same locks. Testing: I've played with a variety of stress tests, including download stress tests on the same APs which caught regressions with commit 5188d545 ("mwifiex: restructure rx_reorder_tbl_lock usage"). I've primarily tested on Marvell 8997 / PCIe, although I've given 8897 / SDIO a quick spin as well. Signed-off-by:
Ganapathi Bhat <gbhat@marvell.com> Signed-off-by:
-
Christoph Hellwig authored
Return the engine type from the function looking at the registers, and just derive the DMA mask from that in the one place we care. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Christoph Hellwig authored
These days drivers are not required to fallback to smaller DMA masks, but can just set the largest mask they support, removing the need for this trial and error logic. Signed-off-by:
-
Christoph Hellwig authored
Return the engine type from the function looking at the registers, and just derive the DMA mask from that in the one place we care. Signed-off-by:
-
Christoph Hellwig authored
These days drivers are not required to fallback to smaller DMA masks, but can just set the largest mask they support, removing the need for this trial and error logic. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
- 26 Jun, 2019 17 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:David S. Miller <davem@davemloft.net>
-
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:
-
