| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
commit 328e203fc35f0b4f6df1c4943f74cf553bcc04f8 upstream.
static code analysis from cppcheck reports:
[drivers/net/wireless/rtlwifi/rtl8188ee/trx.c:322]:
(error) Uninitialized variable: packet_beacon
packet_beacon is not initialized and hence packet_beacon
contains garbage from the stack, so set it to false.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5f9186990ec4579ee5b7a99b3254c29eda479f36 upstream.
Beginning with kernel 3.13, this driver fails on some systems. The problem
was bisected to:
Commit 1bf4bbb4024dcdab5e57634dd8ae1072d42a53ac
Author: Felix Fietkau <nbd@openwrt.org>
Title: mac80211: send control port protocol frames to the VO queue
There is noting wrong with the above commit. The regression occurs because
V0 queue on RTL8192SE cards uses priority 6, not the usual 7. The fix is to
modify the rtl8192se routine that sets the correct transmit queue.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=74541
Reported-by: Alex Miller <almiller_1@yahoo.co.uk>
Tested-by: Alex Miller <almiller_1@yahoo.co.uk>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 2610decdd0b3808ba20471a999835cfee5275f98 upstream.
In commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 entitled "rtlwifi:
rtl8192ce: Fix too long disable of IRQs", Olivier Langlois
<olivier@trillion01.com> fixed a problem caused by an extra long disabling
of interrupts. This patch makes the same fix for rtl8192se.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a53268be0cb9763f11da4f6fe3fb924cbe3a7d4a upstream.
In commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 entitled "rtlwifi:
rtl8192ce: Fix too long disable of IRQs", Olivier Langlois
<olivier@trillion01.com> fixed a problem caused by an extra long disabling
of interrupts. This patch makes the same fix for rtl8192cu.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6b6392715856d563719991e9ce95e773491a8983 upstream.
In commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 entitled "rtlwifi:
rtl8192ce: Fix too long disable of IRQs", Olivier Langlois
<olivier@trillion01.com> fixed a problem caused by an extra long disabling
of interrupts. This patch makes the same fix for rtl8188ee.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit bfc1010c418a22cbebd8b1bd1e75dad6a527a609 upstream.
In commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 entitled "rtlwifi:
rtl8192ce: Fix too long disable of IRQs", Olivier Langlois
<olivier@trillion01.com> fixed a problem caused by an extra long disabling
of interrupts. This patch makes the same fix for rtl8723ae.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 3b3e0efb5c72c4fc940af50b33626b8a78a907dc upstream.
qi->tqi_readyTime is written directly to registers that expect
microseconds as unit instead of TU.
When setting the CABQ ready time, cur_conf->beacon_interval is in TU, so
convert it to microseconds before passing it to ath9k_hw.
This should hopefully fix some Tx DMA issues with buffered multicast
frames in AP mode.
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 a82dda6cd492b8c88952be6f6527f3656f7ac585 upstream.
The current firmware advertises support for uAPSD, but
critical bugs force us to disable the feature.
When a fixed firmware will be available, we will be able to
re-enable uAPSD.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 82e5a649453a3cf23516277abb84273768a1592b upstream.
There is a flow in which we send the host command in SYNC
mode, but we don't take priv->mutex.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1046495
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 12cd43c6ed6da7bf7c5afbd74da6959cda6d056b upstream.
Register B43_MMIO_PSM_PHY_HDR is 16 bit one, so accessing it with 32b
functions isn't safe. On my machine it causes delayed (!) CPU exception:
Disabling lock debugging due to kernel taint
mce: [Hardware Error]: CPU 0: Machine Check Exception: 4 Bank 4: b200000000070f0f
mce: [Hardware Error]: TSC 164083803dc
mce: [Hardware Error]: PROCESSOR 2:20fc2 TIME 1396650505 SOCKET 0 APIC 0 microcode 0
mce: [Hardware Error]: Run the above through 'mcelog --ascii'
mce: [Hardware Error]: Machine check: Processor context corrupt
Kernel panic - not syncing: Fatal machine check on current CPU
Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 8930b05090acd321b1fc7c642528c697cb105c42 upstream.
We should explore all possible columns when searching to be
as resilient as possible to changing conditions. This fixes
for example a scenario where even after a sudden creation of
rssi difference between the 2 antennas we would keep doing MIMO
at a low rate instead of switching to SISO at a higher rate using
the better antenna which was the optimal configuration.
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>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
|
|
This reverts commit eac40d9631a7db43570df859fa8a9922e9623607. It cause
random connection drops on RT5390 PCI adapters.
On Mediatek there is different driver version available for RT53xx chip
based on bus type (2.5.0.3 for PCI and 2.6.1.3 for USB). Hence possibly
we should set registers differently based on bus type. But is also
possible that new driver (i.e. 2.6.1.3) was not verified on RT53xx USB.
Until we figure out how to initialize registers properly for RT53xx just
revert commit eac40d9631a7db43570df859fa8a9922e9623607 since it cause
regression.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Since commit 558ff225de80ac95b132d3a115ddadcd64498b4f (ath9k: fix
ps-poll responses under a-mpdu sessions) non-data frames would have
gotten a sequence number from a TIDs sequence counter instead of
using the global sequence counter.
This can lead to instable connections.
To fix this only select the correct TID if we are processing a
data frame. Furthermore, prevent non-data frames to get a sequence
number from a TID sequence counter by adding a check to
ath_tx_setup_buffer.
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
The commit "ath9k: reduce baseband hang detection false positive rate"
added a delay in the loop checking the baseband state, however it was
unreachable due to previous 'continue' statements.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Commit 1eb4301867 (brcmfmac: fix txglomming scatter-gather packet transfers)
added an allocation of an skb via brcmu_pkt_buf_get_skb() but forgot to
free it on one of the error paths.
Acked-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Dave Jones<davej@fedoraproject.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
|
|
While preparing association request, intersection of device's
VHT capability information and corresponding field advertised
by AP is used.
This patch fixes a couple errors while saving and copying vht_cap
and vht_oper fields from AP's beacon.
Cc: <stable@vger.kernel.org> # 3.9+
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
While preparing association request, intersection of device's HT
capability information and corresponding fields advertised by AP
is used.
This patch fixes an error while copying this field from AP's
beacon.
Cc: <stable@vger.kernel.org>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes
|
|
the current code is directly setting skb->len, which is not correct and
brings problems with HAVE_EFFICIENT_UNALIGNED_ACCESS enabled in config
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Update of the HW IDs for the 7265 series.
Signed-off-by: Oren Givon <oren.givon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Since the statistics handler is asynchrous, it can very well
be that we will handle the statistics (hence the RSSI
fluctuation) when we already disassociated.
Don't WARN on this case.
This solves: https://bugzilla.redhat.com/show_bug.cgi?id=1071998
Cc: <stable@vger.kernel.org> [3.10+]
Fixes: 2b76ef13086f ("iwlwifi: mvm: implement reduced Tx power")
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
|
|
As many Surface Pro I & II users have found out, the mwifiex_usb
doesn't support usb autosuspend, and it has caused some system
stability issues.
Bug 69661 - mwifiex_usb on MS Surface Pro 1 is unstable
Bug 60815 - Interface hangs in mwifiex_usb
Bug 64111 - mwifiex_usb USB8797 crash failed to get signal
information
USB autosuspend get triggered when Surface Pro's AC power is
removed or powertop enables power saving on USB8797 device.
Driver's suspend handler is called here, but resume handler
won't be called until the AC power is put back on or powertop
disables power saving for USB8797.
We need to refactor the suspend/resume handlers to support
usb autosuspend properly. For now let's just remove it.
Cc: <stable@vger.kernel.org> # 3.5+
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
|
|
Only the first packet is currently handled correctly, but then
all others are assumed to have failed which is problematic. Fix
this, marking them all successful instead (since if they're not
then the firmware will have transmitted them as single frames.)
This fixes the lost packet reporting.
Also do a tiny variable scoping cleanup.
Cc: <stable@vger.kernel.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
[Add the dvm part]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Some APs reject STA association request if a listen interval value exceeds
a threshold of 10. Thus, for example, Cisco APs may deny STA associations
returning status code 12 (Association denied due to reason outside the scope
of 802.11 standard) in the association response frame.
Fixing the issue by setting the default IWL_CONN_MAX_LISTEN_INTERVAL value
from 70 to 10.
Cc: <stable@vger.kernel.org> [3.10+]
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
Reviewed-by: Alexander Bondar <alexander.bondar@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
Only set sc->rx.discard_next to rx_stats->rs_more when actually
discarding the current descriptor.
Also, fix a detection of broken descriptors:
First the code checks if the current descriptor is not done.
Then it checks if the next descriptor is done.
Add a check that afterwards checks the first descriptor again, because
it might have been completed in the mean time.
This fixes a regression introduced in
commit 723e711356b5a8a95728a890e254e8b0d47b55cf
"ath9k: fix handling of broken descriptors"
Cc: stable@vger.kernel.org
Reported-by: Marco André Dinis <marcoandredinis@gmail.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Check if the baseband state remains stable, and add a small delay
between register reads.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
