- 20 Nov, 2019 18 commits
-
-
Rafał Miłecki authored
This fixes a minor WARNING in the cfg80211: [ 130.658034] ------------[ cut here ]------------ [ 130.662805] WARNING: CPU: 1 PID: 610 at net/wireless/core.c:954 wiphy_unregister+0xb4/0x198 [cfg80211] Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Rafał Miłecki authored
Keeping interrupts on could result in brcmfmac freeing some resources and then IRQ handlers trying to use them. That was obviously a straight path for crashing a kernel. Example: CPU0 CPU1 ---- ---- brcmf_pcie_reset brcmf_pcie_bus_console_read brcmf_detach ... brcmf_fweh_detach brcmf_proto_detach brcmf_pcie_isr_thread ... brcmf_proto_msgbuf_rx_trigger ... drvr->proto->pd brcmf_pcie_release_irq [ 363.789218] Unable to handle kernel NULL pointer dereference at virtual address 00000038 [ 363.797339] pgd = c0004000 [ 363.800050] [00000038] *pgd=00000000 [ 363.803635] Internal error: Oops: 17 [#1] SMP ARM (...) [ 364.029209] Backtrace: [ 364.031725] [<bf243838>] (brcmf_proto_msgbuf_rx_trigger [brcmfmac]) from [<bf2471dc>] (brcmf_pcie_isr_thread+0x228/0x274 [brcmfmac]) [ 364.043662] r7:00000001 r6:c8ca0000 r5:00010000 r4:c7b4f800 Fixes: 4684997d ("brcmfmac: reset PCIe bus on a firmware crash") Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Yan-Hsuan Chuang authored
Different interfaces have its own link-related power save mechanism. Such as PCI can enter L1 state based on the traffic on the link, and sometimes driver needs to enable/disable it to avoid some issues, like throughput degrade when PCI trying to enter L1 state even if driver is having heavy traffic. For now, rtw88 only supports PCIE chips, and they just need to disable ASPM L1 when driver is not in power save mode, such as IPS and LPS. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Yan-Hsuan Chuang authored
By Realtek's design, there are two HW modules associated for CLKREQ, one is responsible to follow the PCIE host settings, and another is to actually working on it. But the module that is actually working on it is default disabled, and driver should enable that module if host and device have successfully sync'ed with each other. The module is default disabled because sometimes the host does not support it, and if there is any incorrect settings (ex. CLKREQ# is not Bi-Direction), device can be lost and disconnected to the host. So driver should first check after host and device are sync'ed, and the host does support the function and set it in configuration space, then driver can turn on the HW module to working on it. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Yan-Hsuan Chuang authored
Use a for loop to polling DBI/MDIO read/write flags to avoid infinite loop happens Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Yan-Hsuan Chuang authored
Add some register and bit macros to access DBI/MDIO register. This should not change the logic. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Mikhail Karpenko authored
Pass HE interface type data requests between firmware and driver. Signed-off-by: Mikhail Karpenko <mkarpenko@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Mikhail Karpenko authored
Extension information elements have additional field for ID. This commit adds TLV for such elements and a structure for interface HE capabilities communication with firmware. Signed-off-by: Mikhail Karpenko <mkarpenko@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Igor Mitsyanko authored
Firmware floods all packets that need to be flooded (multicast, broadcast, unknown unicast) as required. Tell kernel bridge subsystem it does not need to flood packet itself by marking each incoming frame with skb->offload_fwd_mark flag. Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Igor Mitsyanko authored
Use MAC address of the first active radio as a unique device ID. Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Igor Mitsyanko authored
Add interface ID information to the tail of each transmitted packet so that firmware can know to which interface the packet belongs to. This is only needed if device supports HW switch capability. Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Igor Mitsyanko authored
If firmware reports that it supports hardware switch capabilities, driver needs to track and notify device whenever broadcast domain of a particular network device changes (ie. whenever it's upper master device changes). Firmware needs a unique ID to tell broadcast domains from each other which is an opaque number otherwise. For that purpose we can use netspace:ifidx pair to uniquely identify each broadcast domain: - if netdev is not part of a bridge, then use it's own ifidx as a broadcast domain ID - if netdev is part of a bridge, then use bridge netdev ifidx as broadcast domain ID Firmware makes sure that packets are only forwarded between interfaces marked with the same broadcast domain ID. Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Igor Mitsyanko authored
Currently in case of error when registering network device with the kernel, we won't properly cleanup VIF state in firmware due to DEL_VIF command will not be send to wifi card. Make sure it does. Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Ping-Ke Shih authored
Since read RF register is an indirect access that hardware needs time to accomplish read action, but there's no ready bit, so delay is required to guarantee the read value is correct. After investigating internal documents, these delays are reduced as proper values. Reported-by: Lucas Stach <dev@lynxeye.de> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Ping-Ke Shih authored
rf_lock is used to protect RF register access, but they will not called from interrupt context, so *_irqsave version isn't necessary. Then, these delays don't affect IRQ services. The old code holds spin_lock_irqsave() that will be detected a long delay as below: kworker/-276 4d... 0us : _raw_spin_lock_irqsave kworker/-276 4d... 0us : rtl8723_phy_rf_serial_read <-rtl8723de_phy_set_rf_reg kworker/-276 4d... 1us : rtl8723_phy_query_bb_reg <-rtl8723_phy_rf_serial_read kworker/-276 4d... 3us : rtl8723_phy_set_bb_reg <-rtl8723_phy_rf_serial_read kworker/-276 4d... 4us : __const_udelay <-rtl8723_phy_rf_serial_read kworker/-276 4d... 4us!: delay_mwaitx <-rtl8723_phy_rf_serial_read kworker/-276 4d... 1004us : rtl8723_phy_set_bb_reg <-rtl8723_phy_rf_serial_read [...] Reported-by: Lucas Stach <dev@lynxeye.de> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
zhengbin authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/intel/ipw2x00/ipw2100.c: In function shim__set_security: drivers/net/wireless/intel/ipw2x00/ipw2100.c:5582:9: warning: variable force_update set but not used [-Wunused-but-set-variable] Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
zhengbin authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/intel/ipw2x00/ipw2200.c: In function ipw_wx_set_mlme: drivers/net/wireless/intel/ipw2x00/ipw2200.c:6805:9: warning: variable reason set but not used [-Wunused-but-set-variable] Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
zhengbin authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c: In function brcmf_chip_dmp_get_regaddr: drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:790:5: warning: variable mpnum set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c: In function brcmf_chip_dmp_erom_scan: drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:866:10: warning: variable nsp set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c: In function brcmf_chip_dmp_erom_scan: drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:866:5: warning: variable nmp set but not used [-Wunused-but-set-variable] Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: zhengbin <zhengbin13@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
- 17 Nov, 2019 5 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller authored
Lots of overlapping changes and parallel additions, stuff like that. Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Linus Torvalds authored
Pull crypto fix from Herbert Xu: "This reverts a number of changes to the khwrng thread which feeds the kernel random number pool from hwrng drivers. They were trying to fix issues with suspend-and-resume but ended up causing regressions" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: Revert "hwrng: core - Freeze khwrng thread during suspend"
-
Herbert Xu authored
This reverts commit 03a3bb7a ("hwrng: core - Freeze khwrng thread during suspend"), ff296293 ("random: Support freezable kthreads in add_hwgenerator_randomness()") and 59b56948 ("random: Use wait_event_freezable() in add_hwgenerator_randomness()"). These patches introduced regressions and we need more time to get them ready for mainline. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Ingo Molnar: "Two fixes: disable unreliable HPET on Intel Coffe Lake platforms, and fix a lockdep splat in the resctrl code" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/resctrl: Fix potential lockdep warning x86/quirks: Disable HPET on Intel Coffe Lake platforms
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull timer fix from Ingo Molnar: "Fix integer truncation bug in __do_adjtimex()" * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: ntp/y2038: Remove incorrect time_t truncation
-
- 16 Nov, 2019 17 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull perf fixes from Ingo Molnar: "Misc fixes: a handful of AUX event handling related fixes, a Sparse fix and two ABI fixes" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/core: Fix missing static inline on perf_cgroup_switch() perf/core: Consistently fail fork on allocation failures perf/aux: Disallow aux_output for kernel events perf/core: Reattach a misplaced comment perf/aux: Fix the aux_output group inheritance fix perf/core: Disallow uncore-cgroup events
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netLinus Torvalds authored
Pull networking fixes from David Miller: 1) Fix memory leak in xfrm_state code, from Steffen Klassert. 2) Fix races between devlink reload operations and device setup/cleanup, from Jiri Pirko. 3) Null deref in NFC code, from Stephan Gerhold. 4) Refcount fixes in SMC, from Ursula Braun. 5) Memory leak in slcan open error paths, from Jouni Hogander. 6) Fix ETS bandwidth validation in hns3, from Yonglong Liu. 7) Info leak on short USB request answers in ax88172a driver, from Oliver Neukum. 8) Release mem region properly in ep93xx_eth, from Chuhong Yuan. 9) PTP config timestamp flags validation, from Richard Cochran. 10) Dangling pointers after SKB data realloc in seg6, from Andrea Mayer. 11) Missing free_netdev() in gemini driver, from Chuhong Yuan. * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (56 commits) ipmr: Fix skb headroom in ipmr_get_route(). net: hns3: cleanup of stray struct hns3_link_mode_mapping net/smc: fix fastopen for non-blocking connect() rds: ib: update WR sizes when bringing up connection net: gemini: add missed free_netdev net: dsa: tag_8021q: Fix dsa_8021q_restore_pvid for an absent pvid seg6: fix skb transport_header after decap_and_validate() seg6: fix srh pointer in get_srh() net: stmmac: Use the correct style for SPDX License Identifier octeontx2-af: Use the correct style for SPDX License Identifier ptp: Extend the test program to check the external time stamp flags. mlx5: Reject requests to enable time stamping on both edges. igb: Reject requests that fail to enable time stamping on both edges. dp83640: Reject requests to enable time stamping on both edges. mv88e6xxx: Reject requests to enable time stamping on both edges. ptp: Introduce strict checking of external time stamp options. renesas: reject unsupported external timestamp flags mlx5: reject unsupported external timestamp flags igb: reject unsupported external timestamp flags dp83640: reject unsupported external timestamp flags ...
-
kbuild test robot authored
drivers/net/phy/mscc.c:1683:3-4: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci Fixes: 75a1ccfe ("mscc.c: Add support for additional VSC PHYs") CC: Bryan Whitehead <Bryan.Whitehead@microchip.com> Signed-off-by: kbuild test robot <lkp@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
tcp_mmap is used as a reference program for TCP rx zerocopy, so it is important to point out some potential issues. If multiple threads are concurrently using getsockopt(... TCP_ZEROCOPY_RECEIVE), there is a chance the low-level mm functions compete on shared ptl lock, if vma are arbitrary placed. Instead of letting the mm layer place the chunks back to back, this patch enforces an alignment so that each thread uses a different ptl lock. Performance measured on a 100 Gbit NIC, with 8 tcp_mmap clients launched at the same time : $ for f in {1..8}; do ./tcp_mmap -H 2002:a05:6608:290:: & done In the following run, we reproduce the old behavior by requesting no alignment : $ tcp_mmap -sz -C $((128*1024)) -a 4096 received 32768 MB (100 % mmap'ed) in 9.69532 s, 28.3516 Gbit cpu usage user:0.08634 sys:3.86258, 120.511 usec per MB, 171839 c-switches received 32768 MB (100 % mmap'ed) in 25.4719 s, 10.7914 Gbit cpu usage user:0.055268 sys:21.5633, 659.745 usec per MB, 9065 c-switches received 32768 MB (100 % mmap'ed) in 28.5419 s, 9.63069 Gbit cpu usage user:0.057401 sys:23.8761, 730.392 usec per MB, 14987 c-switches received 32768 MB (100 % mmap'ed) in 28.655 s, 9.59268 Gbit cpu usage user:0.059689 sys:23.8087, 728.406 usec per MB, 18509 c-switches received 32768 MB (100 % mmap'ed) in 28.7808 s, 9.55074 Gbit cpu usage user:0.066042 sys:23.4632, 718.056 usec per MB, 24702 c-switches received 32768 MB (100 % mmap'ed) in 28.8259 s, 9.5358 Gbit cpu usage user:0.056547 sys:23.6628, 723.858 usec per MB, 23518 c-switches received 32768 MB (100 % mmap'ed) in 28.8808 s, 9.51767 Gbit cpu usage user:0.059357 sys:23.8515, 729.703 usec per MB, 14691 c-switches received 32768 MB (100 % mmap'ed) in 28.8879 s, 9.51534 Gbit cpu usage user:0.047115 sys:23.7349, 725.769 usec per MB, 21773 c-switches New behavior (automatic alignment based on Hugepagesize), we can see the system overhead being dramatically reduced. $ tcp_mmap -sz -C $((128*1024)) received 32768 MB (100 % mmap'ed) in 13.5339 s, 20.3103 Gbit cpu usage user:0.122644 sys:3.4125, 107.884 usec per MB, 168567 c-switches received 32768 MB (100 % mmap'ed) in 16.0335 s, 17.1439 Gbit cpu usage user:0.132428 sys:3.55752, 112.608 usec per MB, 188557 c-switches received 32768 MB (100 % mmap'ed) in 17.5506 s, 15.6621 Gbit cpu usage user:0.155405 sys:3.24889, 103.891 usec per MB, 226652 c-switches received 32768 MB (100 % mmap'ed) in 19.1924 s, 14.3222 Gbit cpu usage user:0.135352 sys:3.35583, 106.542 usec per MB, 207404 c-switches received 32768 MB (100 % mmap'ed) in 22.3649 s, 12.2906 Gbit cpu usage user:0.142429 sys:3.53187, 112.131 usec per MB, 250225 c-switches received 32768 MB (100 % mmap'ed) in 22.5336 s, 12.1986 Gbit cpu usage user:0.140654 sys:3.61971, 114.757 usec per MB, 253754 c-switches received 32768 MB (100 % mmap'ed) in 22.5483 s, 12.1906 Gbit cpu usage user:0.134035 sys:3.55952, 112.718 usec per MB, 252997 c-switches received 32768 MB (100 % mmap'ed) in 22.6442 s, 12.139 Gbit cpu usage user:0.126173 sys:3.71251, 117.147 usec per MB, 253728 c-switches Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Soheil Hassas Yeganeh <soheil@google.com> Cc: Arjun Roy <arjunroy@google.com> Acked-by: Soheil Hassas Yeganeh <soheil@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
Load Realtek-provided firmware for RTL8168fp/RTL8117. Unlike the firmware for other chip versions which is for the PHY, firmware for RTL8168fp/RTL8117 is for the MAC. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
Using constant MII_EXPANSION is misleading here because register 0x06 has a different meaning on page 0x0005. Here a proprietary PHY parameter is read by writing the parameter id to register 0x05 on page 0x0005, followed by reading the parameter value from register 0x06. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Russell King authored
Use phy_support_asym_pause() rather than open-coding it. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Guillaume Nault authored
In route.c, inet_rtm_getroute_build_skb() creates an skb with no headroom. This skb is then used by inet_rtm_getroute() which may pass it to rt_fill_info() and, from there, to ipmr_get_route(). The later might try to reuse this skb by cloning it and prepending an IPv4 header. But since the original skb has no headroom, skb_push() triggers skb_under_panic(): skbuff: skb_under_panic: text:00000000ca46ad8a len:80 put:20 head:00000000cd28494e data:000000009366fd6b tail:0x3c end:0xec0 dev:veth0 ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:108! invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 6 PID: 587 Comm: ip Not tainted 5.4.0-rc6+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-2.fc30 04/01/2014 RIP: 0010:skb_panic+0xbf/0xd0 Code: 41 a2 ff 8b 4b 70 4c 8b 4d d0 48 c7 c7 20 76 f5 8b 44 8b 45 bc 48 8b 55 c0 48 8b 75 c8 41 54 41 57 41 56 41 55 e8 75 dc 7a ff <0f> 0b 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 RSP: 0018:ffff888059ddf0b0 EFLAGS: 00010286 RAX: 0000000000000086 RBX: ffff888060a315c0 RCX: ffffffff8abe4822 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff88806c9a79cc RBP: ffff888059ddf118 R08: ffffed100d9361b1 R09: ffffed100d9361b0 R10: ffff88805c68aee3 R11: ffffed100d9361b1 R12: ffff88805d218000 R13: ffff88805c689fec R14: 000000000000003c R15: 0000000000000ec0 FS: 00007f6af184b700(0000) GS:ffff88806c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc8204a000 CR3: 0000000057b40006 CR4: 0000000000360ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_push+0x7e/0x80 ipmr_get_route+0x459/0x6fa rt_fill_info+0x692/0x9f0 inet_rtm_getroute+0xd26/0xf20 rtnetlink_rcv_msg+0x45d/0x630 netlink_rcv_skb+0x1a5/0x220 rtnetlink_rcv+0x15/0x20 netlink_unicast+0x305/0x3a0 netlink_sendmsg+0x575/0x730 sock_sendmsg+0xb5/0xc0 ___sys_sendmsg+0x497/0x4f0 __sys_sendmsg+0xcb/0x150 __x64_sys_sendmsg+0x48/0x50 do_syscall_64+0xd2/0xac0 entry_SYSCALL_64_after_hwframe+0x49/0xbe Actually the original skb used to have enough headroom, but the reserve_skb() call was lost with the introduction of inet_rtm_getroute_build_skb() by commit 404eb77e ("ipv4: support sport, dport and ip_proto in RTM_GETROUTE"). We could reserve some headroom again in inet_rtm_getroute_build_skb(), but this function shouldn't be responsible for handling the special case of ipmr_get_route(). Let's handle that directly in ipmr_get_route() by calling skb_realloc_headroom() instead of skb_clone(). Fixes: 404eb77e ("ipv4: support sport, dport and ip_proto in RTM_GETROUTE") Signed-off-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Merge tag 'wireless-drivers-next-2019-11-15' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for v5.5 Second set of patches for v5.5. Nothing special this time, smaller features to various drivers and of course fixes all over. Major changes: iwlwifi * update scan FW API * bump the supported FW API version * add debug dump collection on assert in WoWLAN * enable adaptive dwell on P2P interfaces ath10k * request for PM_QOS_CPU_DMA_LATENCY to improve firmware initialisation time qtnfmac * add support for getting/setting transmit power * handle MIC failure event from firmware rtl8xxxu * add support for Edimax EW-7611ULB wil6210 * add SPDX license identifiers ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Salil Mehta authored
This patch cleans-up the stray left over code. It has no functionality impact. Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ursula Braun authored
FASTOPEN does not work with SMC-sockets. Since SMC allows fallback to TCP native during connection start, the FASTOPEN setsockopts trigger this fallback, if the SMC-socket is still in state SMC_INIT. But if a FASTOPEN setsockopt is called after a non-blocking connect(), this is broken, and fallback does not make sense. This change complements commit cd206360 ("net/smc: avoid fallback in case of non-blocking connect") and fixes the syzbot reported problem "WARNING in smc_unhash_sk". Reported-by: syzbot+8488cc4cf1c9e09b8b86@syzkaller.appspotmail.com Fixes: e1bbdd57 ("net/smc: reduce sock_put() for fallback sockets") Signed-off-by: Ursula Braun <ubraun@linux.ibm.com> Signed-off-by: Karsten Graul <kgraul@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Matteo Croce authored
A bonding with layer2+3 or layer3+4 hashing uses the IP addresses and the ports to balance packets between slaves. With some network errors, we receive an ICMP error packet by the remote host or a router. If sent by a router, the source IP can differ from the remote host one. Additionally the ICMP protocol has no port numbers, so a layer3+4 bonding will get a different hash than the previous one. These two conditions could let the packet go through a different interface than the other packets of the same flow: # tcpdump -qltnni veth0 |sed 's/^/0: /' & # tcpdump -qltnni veth1 |sed 's/^/1: /' & # hping3 -2 192.168.0.2 -p 9 0: IP 192.168.0.1.2251 > 192.168.0.2.9: UDP, length 0 1: IP 192.168.0.2 > 192.168.0.1: ICMP 192.168.0.2 udp port 9 unreachable, length 36 1: IP 192.168.0.1.2252 > 192.168.0.2.9: UDP, length 0 1: IP 192.168.0.2 > 192.168.0.1: ICMP 192.168.0.2 udp port 9 unreachable, length 36 1: IP 192.168.0.1.2253 > 192.168.0.2.9: UDP, length 0 1: IP 192.168.0.2 > 192.168.0.1: ICMP 192.168.0.2 udp port 9 unreachable, length 36 0: IP 192.168.0.1.2254 > 192.168.0.2.9: UDP, length 0 1: IP 192.168.0.2 > 192.168.0.1: ICMP 192.168.0.2 udp port 9 unreachable, length 36 An ICMP error packet contains the header of the packet which caused the network error, so inspect it and match the flow against it, so we can send the ICMP via the same interface of the previous packet in the flow. Move the IP and port dissect code into a generic function bond_flow_ip() and if we are dissecting an ICMP error packet, call it again with the adjusted offset. # hping3 -2 192.168.0.2 -p 9 1: IP 192.168.0.1.1224 > 192.168.0.2.9: UDP, length 0 1: IP 192.168.0.2 > 192.168.0.1: ICMP 192.168.0.2 udp port 9 unreachable, length 36 1: IP 192.168.0.1.1225 > 192.168.0.2.9: UDP, length 0 1: IP 192.168.0.2 > 192.168.0.1: ICMP 192.168.0.2 udp port 9 unreachable, length 36 0: IP 192.168.0.1.1226 > 192.168.0.2.9: UDP, length 0 0: IP 192.168.0.2 > 192.168.0.1: ICMP 192.168.0.2 udp port 9 unreachable, length 36 0: IP 192.168.0.1.1227 > 192.168.0.2.9: UDP, length 0 0: IP 192.168.0.2 > 192.168.0.1: ICMP 192.168.0.2 udp port 9 unreachable, length 36 Signed-off-by: Matteo Croce <mcroce@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Horatiu Vultur authored
The commit 0c65b2b9 ("net: of_get_phy_mode: Change API to solve int/unit warnings") updated the function of_get_phy_mode declaration. Now it returns an error code and in case the node doesn't contain the property 'phy-mode' or 'phy-connection-type' it returns -EINVAL and would set the phy_interface_t to PHY_INTERFACE_MODE_NA. Ocelot VSC7514 has 4 internal phys which have the phy interface PHY_INTERFACE_MODE_NA. So because of_get_phy_mode would assign PHY_INTERFACE_MODE_NA to phy_mode when there is an error, there is no need to add the error check. Updates for v2: - drop error check because of_get_phy_mode already assigns phy_interface to PHY_INTERFACE_MODE in case of error. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Lobakin authored
Commit 78d3fd0b ("gro: Only use skb_gro_header for completely non-linear packets") back in May'09 (v2.6.31-rc1) has changed the original condition '!skb_headlen(skb)' to 'skb->mac_header == skb->tail' in gro_reset_offset() saying: "Since the drivers that need this optimisation all provide completely non-linear packets" (note that this condition has become the current 'skb_mac_header(skb) == skb_tail_pointer(skb)' later with commmit ced14f68 ("net: Correct comparisons and calculations using skb->tail and skb-transport_header") without any functional changes). For now, we have the following rough statistics for v5.4-rc7: 1) napi_gro_frags: 14 2) napi_gro_receive with skb->head containing (most of) payload: 83 3) napi_gro_receive with skb->head containing all the headers: 20 4) napi_gro_receive with skb->head containing only Ethernet header: 2 With the current condition, fast GRO with the usage of NAPI_GRO_CB(skb)->frag0 is available only in the [1] case. Packets pushed by [2] and [3] go through the 'slow' path, but it's not a problem for them as they already contain all the needed headers in skb->head, so pskb_may_pull() only moves skb->data. The layout of skbs in the fourth [4] case at the moment of dev_gro_receive() is identical to skbs that have come through [1], as napi_frags_skb() pulls Ethernet header to skb->head. The only difference is that the mentioned condition is always false for them, because skb_put() and friends irreversibly alter the tail pointer. They also go through the 'slow' path, but now every single pskb_may_pull() in every single .gro_receive() will call the *really* slow __pskb_pull_tail() to pull headers to head. This significantly decreases the overall performance for no visible reasons. The only two users of method [4] is: * drivers/staging/qlge * drivers/net/wireless/iwlwifi (all three variants: dvm, mvm, mvm-mq) Note that in case with wireless drivers we can't use [1] (napi_gro_frags()) at least for now and mac80211 stack always performs pushes and pulls anyways, so performance hit is inavoidable. At the moment of v2.6.31 the mentioned change was necessary (that's why I don't add the "Fixes:" tag), but it became obsolete since skb_gro_mac_header() has gone in commit a50e233c ("net-gro: restore frag0 optimization"), so we can simply revert the condition in gro_reset_offset() to allow skbs from [4] go through the 'fast' path just like in case [1]. This was tested on a 600 MHz MIPS CPU and a custom driver and this patch gave boosts up to 40 Mbps to method [4] in both directions comparing to net-next, which made overall performance relatively close to [1] (without it, [4] is the slowest). v2: - Add more references and explanations to commit message - Fix some typos ibid - No functional changes Signed-off-by: Alexander Lobakin <alobakin@dlink.ru> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Dag Moxnes authored
Currently WR sizes are updated from rds_ib_sysctl_max_send_wr and rds_ib_sysctl_max_recv_wr when a connection is shut down. As a result, a connection being down while rds_ib_sysctl_max_send_wr or rds_ib_sysctl_max_recv_wr are updated, will not update the sizes when it comes back up. Move resizing of WRs to rds_ib_setup_qp so that connections will be setup with the most current WR sizes. Signed-off-by: Dag Moxnes <dag.moxnes@oracle.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Chuhong Yuan authored
This driver forgets to free allocated netdev in remove like what is done in probe failure. Add the free to fix it. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Kees Cook says: ==================== bnx2x: Remove function casts In order to make the entire kernel usable under Clang's Control Flow Integrity protections, function prototype casts need to be avoided because this will trip CFI checks at runtime (i.e. a mismatch between the caller's expected function prototype and the destination function's prototype). Many of these cases can be found with -Wcast-function-type, which found that bnx2x had a bunch of needless (or at least confusing) function casts. This series removes them all. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-