Age | Commit message (Collapse) | Author |
|
commit 9e4982f6a51a2442f1bb588fee42521b44b4531c upstream.
Like with ath9k, ath5k queues also need to be ordered by priority.
queue_info->tqi_subtype already contains the correct index, so use it
instead of relying on the order of ath5k_hw_setup_tx_queue calls.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b4c82adcba8cb4b23068a6b800ca98da3bee6888 upstream.
Interoperability issues were identified and root caused to
the Smart Fifo watermarks. These issues arose with
NetGear R7000. Fix this.
Fixes: 1f3b0ff8ecce ("iwlwifi: mvm: Add Smart FIFO support")
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 78063d81d353e10cbdd279c490593113b8fdae1c upstream.
Hardware queues are ordered by priority. Use queue index 0 for BK, which
has lower priority than BE.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit ad8fdccf9c197a89e2d2fa78c453283dcc2c343f upstream.
The driver passes the desired hardware queue index for a WMM data queue
in qinfo->tqi_subtype. This was ignored in ath9k_hw_setuptxqueue, which
instead relied on the order in which the function is called.
Reported-by: Hubert Feurstein <h.feurstein@gmail.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit cfd9167af14eb4ec21517a32911d460083ee3d59 upstream.
RT2800 and newer hardware require padding between header and payload if
header length is not multiple of 4.
For historical reasons we also align payload to to 4 bytes boundary, but
such alignment is not needed on modern H/W.
Patch fixes skb_under_panic problems reported from time to time:
https://bugzilla.kernel.org/show_bug.cgi?id=84911
https://bugzilla.kernel.org/show_bug.cgi?id=72471
http://marc.info/?l=linux-wireless&m=139108549530402&w=2
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1087591
Panic happened because we eat 4 bytes of skb headroom on each
(re)transmission when sending frame without the payload and the header
length not being multiple of 4 (i.e. QoS header has 26 bytes). On such
case because paylad_aling=2 is bigger than header_align=0 we increase
header_align by 4 bytes. To prevent that we could change the check to:
if (payload_length && payload_align > header_align)
header_align += 4;
but not aligning payload at all is more effective and alignment is not
really needed by H/W (that has been tested on OpenWrt project for few
years now).
Reported-and-tested-by: Antti S. Lankila <alankila@bel.fi>
Debugged-by: Antti S. Lankila <alankila@bel.fi>
Reported-by: Henrik Asp <solenskiner@gmail.com>
Originally-From: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4e6ce4dc7ce71d0886908d55129d5d6482a27ff9 upstream.
Based on the reference clock, which could be 25MHz or 40MHz,
AR_RTC_DERIVED_CLK is programmed differently for AR9340 and AR9550.
But, when a chip reset is done, processing the initvals
sets the register back to the default value.
Fix this by moving the code in ath9k_hw_init_pll() to
ar9003_hw_override_ini(). Also, do this override for AR9531.
Signed-off-by: Miaoqing Pan <miaoqing@qca.qualcomm.com>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9180ac50716a097a407c6d7e7e4589754a922260 upstream.
The LTR is the handshake between the device and the root
complex about the latency allowed when the bus exits power
save. This configuration was missing and this led to high
latency in the link power up. The end user could experience
high latency in the network because of this.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 805dbe17d1c832ad341f14fae8cedf41b67ca6fa upstream.
The driver is not released when ieee80211_register_hw fails in
mac80211_hwsim_create_radio, leading to the access to the unregistered (and
possibly freed) device in platform_driver_unregister:
[ 0.447547] mac80211_hwsim: ieee80211_register_hw failed (-2)
[ 0.448292] ------------[ cut here ]------------
[ 0.448854] WARNING: CPU: 0 PID: 1 at ../include/linux/kref.h:47 kobject_get+0x33/0x50()
[ 0.449839] CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-00001-gdd46990-dirty #2
[ 0.450813] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 0.451512] 00000000 00000000 78025e38 7967c6c6 78025e68 7905e09b 7988b480 00000000
[ 0.452579] 00000001 79887d62 0000002f 79170bb3 79170bb3 78397008 79ac9d74 00000001
[ 0.453614] 78025e78 7905e15d 00000009 00000000 78025e84 79170bb3 78397000 78025e8c
[ 0.454632] Call Trace:
[ 0.454921] [<7967c6c6>] dump_stack+0x16/0x18
[ 0.455453] [<7905e09b>] warn_slowpath_common+0x6b/0x90
[ 0.456067] [<79170bb3>] ? kobject_get+0x33/0x50
[ 0.456612] [<79170bb3>] ? kobject_get+0x33/0x50
[ 0.457155] [<7905e15d>] warn_slowpath_null+0x1d/0x20
[ 0.457748] [<79170bb3>] kobject_get+0x33/0x50
[ 0.458274] [<7925824f>] get_device+0xf/0x20
[ 0.458779] [<7925b5cd>] driver_detach+0x3d/0xa0
[ 0.459331] [<7925a3ff>] bus_remove_driver+0x8f/0xb0
[ 0.459927] [<7925bf80>] ? class_unregister+0x40/0x80
[ 0.460660] [<7925bad7>] driver_unregister+0x47/0x50
[ 0.461248] [<7925c033>] ? class_destroy+0x13/0x20
[ 0.461824] [<7925d07b>] platform_driver_unregister+0xb/0x10
[ 0.462507] [<79b51ba0>] init_mac80211_hwsim+0x3e8/0x3f9
[ 0.463161] [<79b30c58>] do_one_initcall+0x106/0x1a9
[ 0.463758] [<79b517b8>] ? if_spi_init_module+0xac/0xac
[ 0.464393] [<79b517b8>] ? if_spi_init_module+0xac/0xac
[ 0.465001] [<79071935>] ? parse_args+0x2f5/0x480
[ 0.465569] [<7906b41e>] ? __usermodehelper_set_disable_depth+0x3e/0x50
[ 0.466345] [<79b30dd9>] kernel_init_freeable+0xde/0x17d
[ 0.466972] [<79b304d6>] ? do_early_param+0x7a/0x7a
[ 0.467546] [<79677b1b>] kernel_init+0xb/0xe0
[ 0.468072] [<79075f42>] ? schedule_tail+0x12/0x40
[ 0.468658] [<79686580>] ret_from_kernel_thread+0x20/0x30
[ 0.469303] [<79677b10>] ? rest_init+0xc0/0xc0
[ 0.469829] ---[ end trace ad8ac403ff8aef5c ]---
[ 0.470509] ------------[ cut here ]------------
[ 0.471047] WARNING: CPU: 0 PID: 1 at ../kernel/locking/lockdep.c:3161 __lock_acquire.isra.22+0x7aa/0xb00()
[ 0.472163] DEBUG_LOCKS_WARN_ON(id >= MAX_LOCKDEP_KEYS)
[ 0.472774] CPU: 0 PID: 1 Comm: swapper Tainted: G W 3.17.0-00001-gdd46990-dirty #2
[ 0.473815] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 0.474492] 78025de0 78025de0 78025da0 7967c6c6 78025dd0 7905e09b 79888931 78025dfc
[ 0.475515] 00000001 79888a93 00000c59 7907f33a 7907f33a 78028000 fffe9d09 00000000
[ 0.476519] 78025de8 7905e10e 00000009 78025de0 79888931 78025dfc 78025e24 7907f33a
[ 0.477523] Call Trace:
[ 0.477821] [<7967c6c6>] dump_stack+0x16/0x18
[ 0.478352] [<7905e09b>] warn_slowpath_common+0x6b/0x90
[ 0.478976] [<7907f33a>] ? __lock_acquire.isra.22+0x7aa/0xb00
[ 0.479658] [<7907f33a>] ? __lock_acquire.isra.22+0x7aa/0xb00
[ 0.480417] [<7905e10e>] warn_slowpath_fmt+0x2e/0x30
[ 0.480479] [<7907f33a>] __lock_acquire.isra.22+0x7aa/0xb00
[ 0.480479] [<79078aa5>] ? sched_clock_cpu+0xb5/0xf0
[ 0.480479] [<7907fd06>] lock_acquire+0x56/0x70
[ 0.480479] [<7925b5e8>] ? driver_detach+0x58/0xa0
[ 0.480479] [<79682d11>] mutex_lock_nested+0x61/0x2a0
[ 0.480479] [<7925b5e8>] ? driver_detach+0x58/0xa0
[ 0.480479] [<7925b5e8>] ? driver_detach+0x58/0xa0
[ 0.480479] [<7925b5e8>] driver_detach+0x58/0xa0
[ 0.480479] [<7925a3ff>] bus_remove_driver+0x8f/0xb0
[ 0.480479] [<7925bf80>] ? class_unregister+0x40/0x80
[ 0.480479] [<7925bad7>] driver_unregister+0x47/0x50
[ 0.480479] [<7925c033>] ? class_destroy+0x13/0x20
[ 0.480479] [<7925d07b>] platform_driver_unregister+0xb/0x10
[ 0.480479] [<79b51ba0>] init_mac80211_hwsim+0x3e8/0x3f9
[ 0.480479] [<79b30c58>] do_one_initcall+0x106/0x1a9
[ 0.480479] [<79b517b8>] ? if_spi_init_module+0xac/0xac
[ 0.480479] [<79b517b8>] ? if_spi_init_module+0xac/0xac
[ 0.480479] [<79071935>] ? parse_args+0x2f5/0x480
[ 0.480479] [<7906b41e>] ? __usermodehelper_set_disable_depth+0x3e/0x50
[ 0.480479] [<79b30dd9>] kernel_init_freeable+0xde/0x17d
[ 0.480479] [<79b304d6>] ? do_early_param+0x7a/0x7a
[ 0.480479] [<79677b1b>] kernel_init+0xb/0xe0
[ 0.480479] [<79075f42>] ? schedule_tail+0x12/0x40
[ 0.480479] [<79686580>] ret_from_kernel_thread+0x20/0x30
[ 0.480479] [<79677b10>] ? rest_init+0xc0/0xc0
[ 0.480479] ---[ end trace ad8ac403ff8aef5d ]---
[ 0.495478] BUG: unable to handle kernel paging request at 00200200
[ 0.496257] IP: [<79682de5>] mutex_lock_nested+0x135/0x2a0
[ 0.496923] *pde = 00000000
[ 0.497290] Oops: 0002 [#1]
[ 0.497653] CPU: 0 PID: 1 Comm: swapper Tainted: G W 3.17.0-00001-gdd46990-dirty #2
[ 0.498659] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 0.499321] task: 78028000 ti: 78024000 task.ti: 78024000
[ 0.499955] EIP: 0060:[<79682de5>] EFLAGS: 00010097 CPU: 0
[ 0.500620] EIP is at mutex_lock_nested+0x135/0x2a0
[ 0.501145] EAX: 00200200 EBX: 78397434 ECX: 78397460 EDX: 78025e70
[ 0.501816] ESI: 00000246 EDI: 78028000 EBP: 78025e8c ESP: 78025e54
[ 0.502497] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
[ 0.503076] CR0: 8005003b CR2: 00200200 CR3: 01b9d000 CR4: 00000690
[ 0.503773] Stack:
[ 0.503998] 00000000 00000001 00000000 7925b5e8 78397460 7925b5e8 78397474 78397460
[ 0.504944] 00200200 11111111 78025e70 78397000 79ac9d74 00000001 78025ea0 7925b5e8
[ 0.505451] 79ac9d74 fffffffe 00000001 78025ebc 7925a3ff 7a251398 78025ec8 7925bf80
[ 0.505451] Call Trace:
[ 0.505451] [<7925b5e8>] ? driver_detach+0x58/0xa0
[ 0.505451] [<7925b5e8>] ? driver_detach+0x58/0xa0
[ 0.505451] [<7925b5e8>] driver_detach+0x58/0xa0
[ 0.505451] [<7925a3ff>] bus_remove_driver+0x8f/0xb0
[ 0.505451] [<7925bf80>] ? class_unregister+0x40/0x80
[ 0.505451] [<7925bad7>] driver_unregister+0x47/0x50
[ 0.505451] [<7925c033>] ? class_destroy+0x13/0x20
[ 0.505451] [<7925d07b>] platform_driver_unregister+0xb/0x10
[ 0.505451] [<79b51ba0>] init_mac80211_hwsim+0x3e8/0x3f9
[ 0.505451] [<79b30c58>] do_one_initcall+0x106/0x1a9
[ 0.505451] [<79b517b8>] ? if_spi_init_module+0xac/0xac
[ 0.505451] [<79b517b8>] ? if_spi_init_module+0xac/0xac
[ 0.505451] [<79071935>] ? parse_args+0x2f5/0x480
[ 0.505451] [<7906b41e>] ? __usermodehelper_set_disable_depth+0x3e/0x50
[ 0.505451] [<79b30dd9>] kernel_init_freeable+0xde/0x17d
[ 0.505451] [<79b304d6>] ? do_early_param+0x7a/0x7a
[ 0.505451] [<79677b1b>] kernel_init+0xb/0xe0
[ 0.505451] [<79075f42>] ? schedule_tail+0x12/0x40
[ 0.505451] [<79686580>] ret_from_kernel_thread+0x20/0x30
[ 0.505451] [<79677b10>] ? rest_init+0xc0/0xc0
[ 0.505451] Code: 89 d8 e8 cf 9b 9f ff 8b 4f 04 8d 55 e4 89 d8 e8 72 9d 9f ff 8d 43 2c 89 c1 89 45 d8 8b 43 30 8d 55 e4 89 53 30 89 4d e4 89 45 e8 <89> 10 8b 55 dc 8b 45 e0 89 7d ec e8 db af 9f ff eb 11 90 31 c0
[ 0.505451] EIP: [<79682de5>] mutex_lock_nested+0x135/0x2a0 SS:ESP 0068:78025e54
[ 0.505451] CR2: 0000000000200200
[ 0.505451] ---[ end trace ad8ac403ff8aef5e ]---
[ 0.505451] Kernel panic - not syncing: Fatal exception
Fixes: 9ea927748ced ("mac80211_hwsim: Register and bind to driver")
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Junjie Mao <eternal.n08@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 1ffde699aae127e7abdb98dbdedc2cc6a973a1a1 upstream.
This reverts commit aa11bbf3df026d6b1c6b528bef634fd9de7c2619.
This commit was causing connection issues and is not needed
if IWL_MVM_RS_RSSI_BASED_INIT_RATE is set to false by default.
Regardless of the issues mentioned above, this patch added the
following WARNING:
WARNING: CPU: 0 PID: 3946 at drivers/net/wireless/iwlwifi/mvm/tx.c:190 iwl_mvm_set_tx_params+0x60a/0x6f0 [iwlmvm]()
Got an HT rate for a non data frame 0x8
CPU: 0 PID: 3946 Comm: wpa_supplicant Tainted: G O 3.17.0+ #6
Hardware name: LENOVO 20ANCTO1WW/20ANCTO1WW, BIOS GLET71WW (2.25 ) 07/02/2014
0000000000000009 ffffffff814fa911 ffff8804288db8f8 ffffffff81064f52
0000000000001808 ffff8804288db948 ffff88040add8660 ffff8804291b5600
0000000000000000 ffffffff81064fb7 ffffffffa07b73d0 0000000000000020
Call Trace:
[<ffffffff814fa911>] ? dump_stack+0x41/0x51
[<ffffffff81064f52>] ? warn_slowpath_common+0x72/0x90
[<ffffffff81064fb7>] ? warn_slowpath_fmt+0x47/0x50
[<ffffffffa07a39ea>] ? iwl_mvm_set_tx_params+0x60a/0x6f0 [iwlmvm]
[<ffffffffa07a3cf8>] ? iwl_mvm_tx_skb+0x48/0x3c0 [iwlmvm]
[<ffffffffa079cb9b>] ? iwl_mvm_mac_tx+0x7b/0x180 [iwlmvm]
[<ffffffffa0746ce9>] ? __ieee80211_tx+0x2b9/0x3c0 [mac80211]
[<ffffffffa07492f3>] ? ieee80211_tx+0xb3/0x100 [mac80211]
[<ffffffffa0749c49>] ? ieee80211_subif_start_xmit+0x459/0xca0 [mac80211]
[<ffffffff814116e7>] ? dev_hard_start_xmit+0x337/0x5f0
[<ffffffff81430d46>] ? sch_direct_xmit+0x96/0x1f0
[<ffffffff81411ba3>] ? __dev_queue_xmit+0x203/0x4f0
[<ffffffff8142f670>] ? ether_setup+0x70/0x70
[<ffffffff814e96a1>] ? packet_sendmsg+0xf81/0x1110
[<ffffffff8140625c>] ? skb_free_datagram+0xc/0x40
[<ffffffff813f7538>] ? sock_sendmsg+0x88/0xc0
[<ffffffff813f7274>] ? move_addr_to_kernel.part.20+0x14/0x60
[<ffffffff811c47c2>] ? __inode_wait_for_writeback+0x62/0xb0
[<ffffffff813f7a91>] ? SYSC_sendto+0xf1/0x180
[<ffffffff813f88f9>] ? __sys_recvmsg+0x39/0x70
[<ffffffff8150066d>] ? system_call_fastpath+0x1a/0x1f
---[ end trace cc19a150d311fc63 ]---
which was reported here: https://bugzilla.kernel.org/show_bug.cgi?id=85691
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 664d6a792785cc677c2091038ce10322c8d04ae1 upstream.
0x1b75 0xa200 AirLive WN-200USB wireless 11b/g/n dongle
References: https://bugs.debian.org/766802
Reported-by: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6a06e554daef86c4e8d290284927b081fedb249e upstream.
0x0b05 0x17e8 RT5372 USB 2.0 bgn 2x2 ASUS USB-N14
0x0411 0x0253 RT5572 USB 2.0 abgn 2x2 BUFFALO WLP-U2-300D
0x0df6 0x0078 RT???? Sitecom N300
Cc: Ivo van Doorn <IvDoorn@gmail.com>
Cc: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: users@rt2x00.serialmonkey.com
Cc: linux-wireless@vger.kernel.org
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit ac0372abf8524a7572a9cdaac6495eb2eba20457 upstream.
Signed-off-by: Canek Peláez Valdés <canek@ciencias.unam.mx>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 01f7feeaf4528bec83798316b3c811701bac5d3e upstream.
Two bits control TX power on BBP_R1 register. Correct the mask,
otherwise we clear additional bit on BBP_R1 register, what can have
unknown, possible negative effect.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4f08970f5284dce486f0e2290834aefb2a262189 upstream.
Add 4 missing PCI IDs for the 7260 series.
Signed-off-by: Oren Givon <oren.givon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 87c4790330810fe5caf0172d9320cf24ef19cebe upstream.
The firmware notifies about interface changes through the IF event
which has a NO_IF flag that means host can ignore the event. This
behaviour was introduced in the driver by:
commit 2ee8382fc6c763c76396a6aaff77a27089eed3aa
Author: Arend van Spriel <arend@broadcom.com>
Date: Sat Aug 10 12:27:24 2013 +0200
brcmfmac: ignore IF event if firmware indicates it
It turns out that the IF event for the P2P_DEVICE also has this
flag set, but the event should not be ignored in this scenario.
The mentioned commit caused a regression in 3.12 kernel in creation
of the P2P_DEVICE interface.
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Reviewed-by: Daniel (Deognyoun) Kim <dekim@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c66517165610b911e4c6d268f28d8c640832dbd1 upstream.
The Sitecom WLA-2102 adapter uses this driver.
Reported-by: Nico Baggus <nico-linux@noci.xs4all.nl>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Nico Baggus <nico-linux@noci.xs4all.nl>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit aa11bbf3df026d6b1c6b528bef634fd9de7c2619 upstream.
Using the LQ table which is initially set according to
the rssi could lead to EAPOLs being sent in high legacy
rates like 54mbps.
It's better to avoid sending EAPOLs in high rates as it reduces
the chances of a successful 4-Way handshake.
Avoid this and treat them like other mgmt frames which would
initially get sent at the basic rate.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 22d059a5c7c5de61e53c88e30b65e55fbfd91e91 upstream.
The chip is able to transmit up to 22dBm, so set
the constant appropriately.
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 86974bff066dd8b98be46d7c7d3aba89034f0833 upstream.
This code was broken on big endian systems. Sparse didn't
catch the bug since the firmware command was not tagged as
little endian.
Fix the bug for big endian systems and tag the field in the
firmware command to prevent such issues in the future.
Fixes: 1f3b0ff8ec ("iwlwifi: mvm: Add Smart FIFO support")
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f47f46d7b09cf1d09e4b44b6cc4dd7d68a08028c upstream.
This reverts commit 43d826ca5979927131685cc2092c7ce862cb91cd.
This commit caused packet loss.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 671796dd96b6cd85b75fba9d3007bcf7e5f7c309 upstream.
The driver assumes that endpoint 4 is always an interrupt endpoint.
Unfortunately the type differs between high-speed and full-speed
configurations while in the former case it is indeed an interrupt
endpoint this is not true for the latter case - here it is a bulk
endpoint. When sending URBs with the wrong type the kernel will
generate a warning message including backtrace. In this specific
case there will be a huge amount of warnings which can bring the system
to freeze.
To fix this we are now sending URBs to endpoint 4 using the type
found in the endpoint descriptor.
A side note: The carl9170 firmware currently specifies endpoint 4 as
interrupt endpoint even in the full-speed configuration but this has
no relevance because before this firmware is loaded the endpoint type
is as described above and after the firmware is running the stick is not
reenumerated and so the old descriptor is used.
Signed-off-by: Ronald Wahl <ronald.wahl@raritan.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c01fac1c77a00227f706a1654317023e3f4ac7f0 upstream.
If an aggregation session fails, frames still end up in the driver queue
with IEEE80211_TX_CTL_AMPDU set.
This causes tx for the affected station/tid to stall, since
ath_tx_get_tid_subframe returning packets to send.
Fix this by clearing IEEE80211_TX_CTL_AMPDU as long as no aggregation
session is running.
Reported-by: Antonio Quartulli <antonio@open-mesh.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit dc271ee0d04d12d6bfabacbec803289a7072fbd9 upstream.
Firmware folks seem say that this flag can make trouble.
Drop it. The advantage of CTS to self is that it slightly
reduces the cost of the protection, but make the protection
less reliable.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit d76744a93246eccdca1106037e8ee29debf48277 upstream.
https://bugzilla.kernel.org/show_bug.cgi?id=70191
https://bugzilla.kernel.org/show_bug.cgi?id=77581
It is observed that sometimes Tx packet is downloaded without
adding driver's txpd header. This results in firmware parsing
garbage data as packet length. Sometimes firmware is unable
to read the packet if length comes out as invalid. This stops
further traffic and timeout occurs.
The root cause is uninitialized fields in tx_info(skb->cb) of
packet used to get garbage values. In this case if
MWIFIEX_BUF_FLAG_REQUEUED_PKT flag is mistakenly set, txpd
header was skipped. This patch makes sure that tx_info is
correctly initialized to fix the problem.
Reported-by: Andrew Wiley <wiley.andrew.j@gmail.com>
Reported-by: Linus Gasser <list@markas-al-nour.org>
Reported-by: Michael Hirsch <hirsch@teufel.de>
Tested-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Maithili Hinge <maithili@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 43d826ca5979927131685cc2092c7ce862cb91cd upstream.
We should always prefer to use full RTS protection. Using
CTS to self gives a meaningless improvement, but this flow
is much harder for the firmware which is likely to have
issues with it.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b3c063ae7279981f7161e63b44f214c62f122b32 upstream.
Add one more 7265 series HW ID.
Edit one existing 7265 series HW ID.
Signed-off-by: Oren Givon <oren.givon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit ffa216bb5eecfce0f01b0b2a95d5c320dde90005 upstream.
brcmfmac has been broken on my cubietruck with a BCM43362:
brcmfmac: brcmf_chip_recognition: found AXI chip: BCM43362, rev=1
brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
since commit 53036261033: "brcmfmac: update core reset and disable routines".
The problem is that since this commit brcmf_chip_ai_resetcore no longer sets
BCMA_IOCTL itself before bringing the core out of reset, instead relying on
brcmf_chip_ai_coredisable to do so. But brcmf_chip_ai_coredisable is a nop
of the chip is already in reset. This patch modifies brcmf_chip_ai_coredisable
to always set BCMA_IOCTL even if the core is already in reset.
This fixes brcmfmac hanging in firmware loading on my board.
Cc: stable@vger.kernel.org # v3.14
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[arend@broadcom.com: rebase patch on linux-3.14.y branch]
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 2fc68eb122c7ea6cd5be1fe7d6650c0beb2f4f40 upstream.
Support for firmware rev 508+ was added years ago, but we never noticed
it reports channel in a different way for G-PHY devices. Instead of
offset from 2400 MHz it simply passes channel id (AKA hw_value).
So far it was (most probably) affecting monitor mode users only, but
the following recent commit made it noticeable for quite everybody:
commit 3afc2167f60a327a2c1e1e2600ef209a3c2b75b7
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date: Tue Mar 4 16:50:13 2014 +0200
cfg80211/mac80211: ignore signal if the frame was heard on wrong channel
Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 501fd9895c1d7d8161ed56698ae2fccb10ef14f5 upstream.
Some races with the hardware can happen when we take
ownership of the device. Don't give up after the first try.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 616a8394b5df8c88f4dd416f4527439a4e365034 upstream.
As reported by Niels, starting rfkill polling during device probe
(commit e2bc7c5, generally sane change) broke rfkill on rt2500pci
device. I considered that bug as some initalization issue, which
should be fixed on rt2500pci specific code. But after several
attempts (see bug report for details) we fail to find working solution.
Hence I decided to revert to old behaviour on rt2500pci to fix
regression.
Additionally patch also unregister rfkill on device remove instead
of ifconfig down, what was another issue introduced by bad commit.
Bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=73821
Fixes: e2bc7c5f3cb8 ("rt2x00: Fix rfkill_polling register function.")
Bisected-by: Niels <nille0386@googlemail.com>
Reported-and-tested-by: Niels <nille0386@googlemail.com>
Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 8edcb0ba0d56f5914eef11eda6db8bfe74eb9ca8 upstream.
On USB we can not get atomically TKIP key. We have to disable support
for TKIP acceleration on USB hardware to avoid bug as showed bellow.
[ 860.827243] BUG: scheduling while atomic: hostapd/3397/0x00000002
<snip>
[ 860.827280] Call Trace:
[ 860.827282] [<ffffffff81682ea6>] dump_stack+0x4d/0x66
[ 860.827284] [<ffffffff8167eb9b>] __schedule_bug+0x47/0x55
[ 860.827285] [<ffffffff81685bb3>] __schedule+0x733/0x7b0
[ 860.827287] [<ffffffff81685c59>] schedule+0x29/0x70
[ 860.827289] [<ffffffff81684f8a>] schedule_timeout+0x15a/0x2b0
[ 860.827291] [<ffffffff8105ac50>] ? ftrace_raw_event_tick_stop+0xc0/0xc0
[ 860.827294] [<ffffffff810c13c2>] ? __module_text_address+0x12/0x70
[ 860.827296] [<ffffffff81686823>] wait_for_completion_timeout+0xb3/0x140
[ 860.827298] [<ffffffff81080fc0>] ? wake_up_state+0x20/0x20
[ 860.827301] [<ffffffff814d5b3d>] usb_start_wait_urb+0x7d/0x150
[ 860.827303] [<ffffffff814d5cd5>] usb_control_msg+0xc5/0x110
[ 860.827305] [<ffffffffa02fb0c6>] rt2x00usb_vendor_request+0xc6/0x160 [rt2x00usb]
[ 860.827307] [<ffffffffa02fb215>] rt2x00usb_vendor_req_buff_lock+0x75/0x150 [rt2x00usb]
[ 860.827309] [<ffffffffa02fb393>] rt2x00usb_vendor_request_buff+0xa3/0xe0 [rt2x00usb]
[ 860.827311] [<ffffffffa023d1a3>] rt2x00usb_register_multiread+0x33/0x40 [rt2800usb]
[ 860.827314] [<ffffffffa05805f9>] rt2800_get_tkip_seq+0x39/0x50 [rt2800lib]
[ 860.827321] [<ffffffffa0480f88>] ieee80211_get_key+0x218/0x2a0 [mac80211]
[ 860.827322] [<ffffffff815cc68c>] ? __nlmsg_put+0x6c/0x80
[ 860.827329] [<ffffffffa051b02e>] nl80211_get_key+0x22e/0x360 [cfg80211]
Reported-and-tested-by: Peter Wu <lekensteyn@gmail.com>
Reported-and-tested-by: Pontus Fuchs <pontus.fuchs@gmail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b804eeb6649d75caeccbeae9f5623fc7b8bdfdfa upstream.
The per rate stats should be cleared when aggregation state changes
to avoid making rate scale decisions based on throughput figures which
were collected prior to the aggregation state change and are now stale.
While at it make sure any clearing of the per rate stats will get logged.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 3ca71f603bb1a0f55e1ba24618ba45617bc36f70 upstream.
instead of duplicating the same loop multiple times,
use a new function for it.
this will be later used also for clearing other
windows in the table.
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7bacc782270ff7db3b9f29fa5d24ad2ee1e8e81d upstream.
This feature has been causing trouble - disable it for now.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a6bc92803e7f765e02c923cf37c8e280e729642a upstream.
A few entries were wrong and this caused throughput issues.
Fixes: dac94da8dba3 ("iwlwifi: mvm: new BT Coex API")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 1c4abec0baf25ffb92a28cc99d4231feeaa4d3f3 upstream.
There was a deadlock in monitor mode when we were setting the
channel if the channel was not 1.
======================================================
[ INFO: possible circular locking dependency detected ]
3.14.3 #4 Not tainted
-------------------------------------------------------
iw/3323 is trying to acquire lock:
(&local->chanctx_mtx){+.+.+.}, at: [<ffffffffa062e2f2>] ieee80211_vif_release_channel+0x42/0xb0 [mac80211]
but task is already holding lock:
(&local->iflist_mtx){+.+...}, at: [<ffffffffa0609e0a>] ieee80211_set_monitor_channel+0x5a/0x1b0 [mac80211]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&local->iflist_mtx){+.+...}:
[<ffffffff810d95bb>] __lock_acquire+0xb3b/0x13b0
[<ffffffff810d9ee0>] lock_acquire+0xb0/0x1f0
[<ffffffff817eb9c8>] mutex_lock_nested+0x78/0x4f0
[<ffffffffa06225cf>] ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
[<ffffffffa0518189>] iwl_mvm_recalc_multicast+0x49/0xa0 [iwlmvm]
[<ffffffffa051822e>] iwl_mvm_configure_filter+0x4e/0x70 [iwlmvm]
[<ffffffffa05e6d43>] ieee80211_configure_filter+0x153/0x5f0 [mac80211]
[<ffffffffa05e71f5>] ieee80211_reconfig_filter+0x15/0x20 [mac80211]
[snip]
-> #1 (&mvm->mutex){+.+.+.}:
[<ffffffff810d95bb>] __lock_acquire+0xb3b/0x13b0
[<ffffffff810d9ee0>] lock_acquire+0xb0/0x1f0
[<ffffffff817eb9c8>] mutex_lock_nested+0x78/0x4f0
[<ffffffffa0517246>] iwl_mvm_add_chanctx+0x56/0xe0 [iwlmvm]
[<ffffffffa062ca1e>] ieee80211_new_chanctx+0x13e/0x410 [mac80211]
[<ffffffffa062d953>] ieee80211_vif_use_channel+0x1c3/0x5a0 [mac80211]
[<ffffffffa06035ab>] ieee80211_add_virtual_monitor+0x1ab/0x6b0 [mac80211]
[<ffffffffa06052ea>] ieee80211_do_open+0xe6a/0x15a0 [mac80211]
[<ffffffffa0605a79>] ieee80211_open+0x59/0x60 [mac80211]
[snip]
-> #0 (&local->chanctx_mtx){+.+.+.}:
[<ffffffff810d6cb7>] check_prevs_add+0x977/0x980
[<ffffffff810d95bb>] __lock_acquire+0xb3b/0x13b0
[<ffffffff810d9ee0>] lock_acquire+0xb0/0x1f0
[<ffffffff817eb9c8>] mutex_lock_nested+0x78/0x4f0
[<ffffffffa062e2f2>] ieee80211_vif_release_channel+0x42/0xb0 [mac80211]
[<ffffffffa0609ec3>] ieee80211_set_monitor_channel+0x113/0x1b0 [mac80211]
[<ffffffffa058fb37>] cfg80211_set_monitor_channel+0x77/0x2b0 [cfg80211]
[<ffffffffa056e0b2>] __nl80211_set_channel+0x122/0x140 [cfg80211]
[<ffffffffa0581374>] nl80211_set_wiphy+0x284/0xaf0 [cfg80211]
[snip]
other info that might help us debug this:
Chain exists of:
&local->chanctx_mtx --> &mvm->mutex --> &local->iflist_mtx
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&local->iflist_mtx);
lock(&mvm->mutex);
lock(&local->iflist_mtx);
lock(&local->chanctx_mtx);
*** DEADLOCK ***
This deadlock actually occurs:
INFO: task iw:3323 blocked for more than 120 seconds.
Not tainted 3.14.3 #4
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
iw D ffff8800c8afcd80 4192 3323 3322 0x00000000
ffff880078fdb7e0 0000000000000046 ffff8800c8afcd80 ffff880078fdbfd8
00000000001d5540 00000000001d5540 ffff8801141b0000 ffff8800c8afcd80
ffff880078ff9e38 ffff880078ff9e38 ffff880078ff9e40 0000000000000246
Call Trace:
[<ffffffff817ea841>] schedule_preempt_disabled+0x31/0x80
[<ffffffff817ebaed>] mutex_lock_nested+0x19d/0x4f0
[<ffffffffa06225cf>] ? ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
[<ffffffffa06225cf>] ? ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
[<ffffffffa052a680>] ? iwl_mvm_power_mac_update_mode+0xc0/0xc0 [iwlmvm]
[<ffffffffa06225cf>] ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
[<ffffffffa0529357>] _iwl_mvm_power_update_binding+0x27/0x80 [iwlmvm]
[<ffffffffa0516eb1>] iwl_mvm_unassign_vif_chanctx+0x81/0xc0 [iwlmvm]
[<ffffffffa062d3ff>] __ieee80211_vif_release_channel+0xdf/0x470 [mac80211]
[<ffffffffa062e2fa>] ieee80211_vif_release_channel+0x4a/0xb0 [mac80211]
[<ffffffffa0609ec3>] ieee80211_set_monitor_channel+0x113/0x1b0 [mac80211]
[<ffffffffa058fb37>] cfg80211_set_monitor_channel+0x77/0x2b0 [cfg80211]
[<ffffffffa056e0b2>] __nl80211_set_channel+0x122/0x140 [cfg80211]
[<ffffffffa0581374>] nl80211_set_wiphy+0x284/0xaf0 [cfg80211]
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=75541
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 83f7a85f1134c6e914453f5747435415a23d516b upstream.
In case RFKILL is in KILL position, the NIC will issue an
interrupt straight away. This interrupt won't be sent
because it is masked in the hardware.
But if our interrupt service routine is called for another
reason (SHARED_IRQ), then we'll look at the interrupt cause
and service it. This can cause bad things if we are not
ready yet.
Explicitly clean the interrupt cause register to make sure
we won't service anything before we are ready to.
Reported-and-tested-by: Alexander Monakov <amonakov@gmail.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 8fc1e8c240aab968db658b2d8d079b4391207a36 upstream.
When brcm80211 firmware is not installed networking hangs.
A deadlock happens because we call ieee80211_unregister_hw()
from the .start callback of struct ieee80211_ops. When .start
is called we are under rtnl lock and ieee80211_unregister_hw()
tries to take it again.
Function call stack:
dev_change_flags()
__dev_change_flags()
__dev_open()
ASSERT_RTNL() <-- Assert rtnl lock
ops->ndo_open()
.ndo_open = ieee80211_open,
ieee80211_open()
ieee80211_do_open()
drv_start()
local->ops->start()
.start = brcms_ops_start,
brcms_ops_start()
brcms_remove()
ieee80211_unregister_hw()
rtnl_lock() <-- Here we deadlock
Introduced by:
commit 25b5632fb35ca61b8ae3eee235edcdc2883f7a5e
("brcmsmac: request firmware in .start() callback")
This patch fixes the bug by removing the call to brcms_remove()
and moves the brcms_request_fw() call to the top of the .start
callback to not initiate anything unless firmware is installed.
Signed-off-by: Emil Goode <emilgoode@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 3234f5b06fc3094176a86772cc64baf3decc98fc upstream.
Fixes: a53268be0cb9 ('rtlwifi: rtl8192cu: Fix too long disable of IRQs')
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 8834d3608cc516f13e2e510f4057c263f3d2ce42 upstream.
When disable beaconing we clear register with beacon and newer set it
back, what make we stop send beacons infinitely.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 0229cdafb6f67064a217591d48b0f6abf14e8385 upstream.
If we have no beacon data before association, delay smart FIFO
enablement until after we have this data.
Not doing so can cause association failures in extremely silent
environments (usually only a shielded box/room) as beacon RX is
not sent to the host immediately, and then the association time
event ends without the host receiving any beacon even though it
was on the air - it's just stuck on the FIFO.
Fixes: 1f3b0ff8ecce ("iwlwifi: mvm: Add Smart FIFO support")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 431031851ea72a25abb9ad4df56a0f3b997e3026 upstream.
This will allow to load the new firmware.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 87d5e4155c0088e6766b4f0193b63fa0eab71220 upstream.
After being idle for a long time (>5sec) the rs statistics
will be stale so we prefer to reset rs and start from legacy
rates again. This gives better results when the attenuation
increased signficantly (e.g. we got further from the AP) and
after a while we start Tx
Note that the first Tx after the idle period will still go out
in the old modulation and rate but this seemed a simpler approach
compared to adding a timer or modifying mac80211 for this.
The negative impact is negligble as we'll recover quickly.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e53839eb9882c99d3781eab0fe1b2d4369a6a2cc upstream.
Change the down/upscale decision logic a bit to be based
on different success ratio thresholds. This fixes the implementation
compared to the rate scale algorithm which was planned to yield
optimal results. Also fix a case where a lower rate wasn't explored
despite being a potential for better throughput.
While at it rewrite rs_get_rate_action to be more clear and clean.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit d8fff919ecd7820084675c2814913445e95640ac upstream.
Don't search columns which are unlikely to succeed as previous
columns searched with less aggressive modulation failed.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit fd7dbee51b3d98402edb11fec0c93d96476e0ae1 upstream.
Allow switching back to legacy Tx columns so we'll stop doing
HT/VHT in case we're far from the AP. Stop active aggregation when
making a deciding to stay in a legacy column.
Despite having low legacy rates in the LQ table lower entries
it doesn't help much in case we're doing aggregations as the
aggregation was being transmitted in the initial rate of the table.
This should help traffic stalls when far from the AP.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 80f2679e589503bd6cbaaa1f9c1cd9dd7dfae032 upstream.
Add 2 new HW IDs for the 7265 series.
Signed-off-by: Oren Givon <oren.givon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit d9088f60425e0acd8a8f05fdfcfdd288d3258641 upstream.
mimo_delim was always set to 0 instead of pointing to
the first SISO entry after MIMO rates.
This can cause keep transmitting in MIMO even when we shouldn't.
For example when the peer is requesting static SMPS.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 08a732f4e4a842f0101e5ea03d79e9d613ffadbe upstream.
It was missing.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c0da71ff4d2cbf113465bff9a7c413154be25a89 upstream.
Some fields are missing from the event mailbox
struct definitions, which cause issues when
trying to handle some events.
Add the missing fields in order to align the
struct size (without adding actual support
for the new fields).
Reported-and-tested-by: Imre Kaloz <kaloz@openwrt.org>
Fixes: 028e724 ("wl18xx: move to new firmware (wl18xx-fw-3.bin)")
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|