This issue was reported on the wireless list (see [1]) in which
brcmsmac ran into a fatal error:
[ 588.284074] brcmsmac bcma0:0: frameid != txh->TxFrameID
[ 588.284098] brcmsmac bcma0:0: MI_TFS: fatal
[ 588.284103] brcmsmac bcma0:0: wl0: fatal error, reinitializing
[ 588.286208] ieee80211 phy0: Hardware restart was requested
The tx status feedback is processed in a loop limiting the number of
frames processed in one run. The code terminate processing when the
limit is reached regardless the txstatus value read from the device
register. When that status is is flagged as being valid it must be
processed as the hardware will clear it after is has been read.
Bisecting was done by Seth Forshee and showed following commit as the
culprit:
commit 57fe504817
Author: Piotr Haber <phaber@broadcom.com>
Date: Wed Nov 28 21:44:07 2012 +0100
brcmsmac: fix bounds checking in tx/rx
[1] http://www.spinics.net/lists/linux-wireless/msg101293.html
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Tested-by: Seth Forshee <seth.forshee@canonical.com>
Reviewed-by: Hante Meuleman <meuleman@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>
We do a:
sprintf(buf, " Last beacon: %ums ago",
elapsed_jiffies_msecs(bss->ts));
elapsed_jiffies_msecs() can return a 10 digit number so "buf" needs to
be 31 characters long.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This reverts commit f590dcec94
which has been reported to cause issues.
See https://lkml.org/lkml/2013/1/20/4 for further details.
Cc: stable@vger.kernel.org [3.7]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add missing "!" as we are supposed to check "!card->adapter"
in PCIe suspend handler.
Cc: "3.2+" <stable@vger.kernel.org>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Reviewed-by: Sergey V. <sftp.mtuci@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Chain swapping should only be enabled when the EEPROM chainmask is set to 5,
regardless of what the runtime chainmask is.
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The kbuild test robot reports the following warning with x86_64-randconfig-x955:
warning: (RTL8192CE && RTL8192SE && RTL8192DE && RTL8723AE && RTL8192CU) selects
RTLWIFI which has unmet direct dependencies (NETDEVICES && WLAN &&
(RTL8192CE || RTL8192CU || RTL8192SE || RTL8192DE))
This warning was introduced in commit a290593, "rtlwifi: Modify files for addition
of rtl8723ae", and is d ue to a missing dependence of RTLWIFI on RTL8723AE.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: kbuild test robot <fengguang.wu@intel.com>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We do not correctly change interface type when switching from
IBSS mode to STA mode, that results in microcode errors.
Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=886946
Reported-by: Jaroslav Skarvada <jskarvad@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Mesh PERR action frames are robust and thus may be encrypted, so add
proper head/tailroom to allow this. Fixes this warning when operating
a Mesh STA on ath5k:
WARNING: at net/mac80211/wpa.c:427 ccmp_encrypt_skb.isra.5+0x7b/0x1a0 [mac80211]()
Call Trace:
[<c011c5e7>] warn_slowpath_common+0x63/0x78
[<c011c60b>] warn_slowpath_null+0xf/0x13
[<e090621d>] ccmp_encrypt_skb.isra.5+0x7b/0x1a0 [mac80211]
[<e090685c>] ieee80211_crypto_ccmp_encrypt+0x1f/0x37 [mac80211]
[<e0917113>] invoke_tx_handlers+0xcad/0x10bd [mac80211]
[<e0917665>] ieee80211_tx+0x87/0xb3 [mac80211]
[<e0918932>] ieee80211_tx_pending+0xcc/0x170 [mac80211]
[<c0121c43>] tasklet_action+0x3e/0x65
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
A user reported warnings in ath5k due to transmitting frames with no
rates set up. The frames were Mesh PERR frames, and some debugging
showed an empty control block with just the vif pointer:
> [ 562.522682] XXX txinfo: 00000000: 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 ................
> [ 562.522688] XXX txinfo: 00000010: 00 00 00 00 00 00 00 00 54 b8 f2
> db 00 00 00 00 ........T.......
> [ 562.522693] XXX txinfo: 00000020: 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 ................
Set the IEEE80211_TX_INTFL_NEED_TXPROCESSING flag to ensure that
rate control gets run before the frame is sent.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Channel contexts are not always used with monitor interfaces. If no channel
context is set, use the oper channel, otherwise tx fails.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
[check local->use_chanctx]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since:
commit b23b025fe2
Author: Ben Greear <greearb@candelatech.com>
Date: Fri Feb 4 11:54:17 2011 -0800
mac80211: Optimize scans on current operating channel.
we do not disable PS while going back to operational channel (on
ieee80211_scan_state_suspend) and deffer that until scan finish.
But since we are allowed to send frames, we can send a frame to AP
without PM bit set, so disable PS on AP side. Then when we switch
to off-channel (in ieee80211_scan_state_resume) we do not enable PS.
Hence we are off-channel with PS disabled, frames are not buffered
by AP.
To fix remove offchannel_ps_disable argument and always enable PS when
going off-channel and disable it when going on-channel, like it was
before.
Cc: stable@vger.kernel.org # 2.6.39+
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Tested-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
During FT roaming, wpa_supplicant attempts to set the
key before association. This used to be rejected, but
as a side effect of my commit 66e67e4189
("mac80211: redesign auth/assoc") the key was accepted
causing hardware crypto to not be used for it as the
station isn't added to the driver yet.
It would be possible to accept the key and then add it
to the driver when the station has been added. However,
this may run into issues with drivers using the state-
based station adding if they accept the key only after
association like it used to be.
For now, revert to the behaviour from before the auth
and assoc change.
Cc: stable@vger.kernel.org
Reported-by: Cédric Debarge <cedric.debarge@acksys.fr>
Tested-by: Cédric Debarge <cedric.debarge@acksys.fr>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The rate scaling won't treat the information in a frame
with IEEE80211_TX_CTL_AMPDU set if IEEE80211_TX_STAT_AMPDU
is cleared. But all the frames coming from an AGG tx queue
have IEEE80211_TX_CTL_AMPDU set, and IEEE80211_TX_STAT_AMPDU
is set only if the frame was sent in an AMPDU.
This means that all the data in frames in AGG tx queues that
aren't sent as an AMPDU is thrown away.
This is even more harmful when in bad link conditions, the
frames are sent in an AMPDU and then finally sent as single
frame. So a lot of failures weren't reported and the rate
scaling got stuck in high rates leading to very poor
connectivity.
Fix that by clearing IEEE80211_TX_CTL_AMPDU when the frame
isn't part of an AMPDU.
This bug was introduced by
2eb81a40aa
iwlwifi: don't clear CTL_AMPDU on frame status
This fix basically reverts the aforementioned commit.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fixes a reported CPU soft lockup where the tasklet tries to acquire the
lock and blocks while ath_prepare_reset (holding the lock) waits for it
to complete.
Cc: stable@vger.kernel.org
Reported-by: Robert Shade <robert.shade@gmail.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The commit "ath9k: fix rx flush handling" added a deadlock that happens
because ath_rx_tasklet is called in a section that has already taken the
rx buffer lock.
It seems that the only purpose of the rxbuflock was a band-aid fix to the
reset vs rx tasklet race, which has been properly fixed in the commit
"ath9k: add a better fix for the rx tasklet vs rx flush race".
Now that the fix is in, we can safely remove the lock to avoid such issues.
Cc: stable@vger.kernel.org
Reported-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On hardware reintialization reference count of
already existing timers would be increased again.
This leads to problems on module unloading.
Cc: stable@vger.kernel.org
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Piotr Haber <phaber@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Right now the rx flush is not doing anything useful on AR9003+, as it only
works if the buffers in the rx FIFO have not been purged yet, as is done
by ath_stoprecv.
To fix this, always call ath_flushrecv from within ath_stoprecv before
the FIFO is emptied, but still after the hw receive path has been stopped.
This ensures that frames received (and ACKed by the hardware) shortly before
a reset will be seen by the software, which should improve A-MPDU session
stability.
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Ensure that the rx tasklet is no longer running when entering the reset path.
Also remove the distinction between flush and no-flush frame processing.
If a frame has been received and ACKed by the hardware, the stack needs to see
it, so that the BA receive window does not go out of sync.
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
During teardown, mac80211 will not return a new beacon. This is normal and
handled properly in the driver, so there's no need to spam the user with a kernel
warning here.
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When the next beacon is sent, the ath_buf from the previous run is reused.
If getting a new beacon from mac80211 fails, bf->bf_mpdu is not reset, yet
the skb is freed, leading to a double-free on the next beacon tx attempt,
resulting in a system crash.
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On AR9300 the rx FIFO needs to be empty during reset to ensure that no
further DMA activity is generated, otherwise it might lead to memory
corruption issues.
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
SKBs that are allocated in the HTC layer do not have callbacks
registered and hence ended up not being freed, Fix this by freeing
them properly in the TX completion routine.
Cc: <stable@vger.kernel.org>
Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
BAND_G is implicit when BAND_GN is present.
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>
Currently "adapter->config_bands" is updated during infra
association only if channel is provided by user in "iw connect"
command. config_bands is used while preparing association
request to calculate supported rates by intersecting our rates
with the rates advertised by AP.
There is corner case in which we include zero rates in
supported rates TLV based on previous IBSS network history,
which leads to association failure.
This patch fixes the problem by correctly updating config_bands.
Cc: "3.7.y" <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>
The length parameter should be sizeof(req->name) - 1 because there is no
guarantee that string provided by userspace will contain the trailing
'\0'.
Can be easily reproduced by manually setting req->name to 128 non-zero
bytes prior to ioctl(HIDPCONNADD) and checking the device name setup on
input subsystem:
$ cat /sys/devices/pnp0/00\:04/tty/ttyS0/hci0/hci0\:1/input8/name
AAAAAA[...]AAAAAAAAf0:af:f0:af:f0:af
("f0:af:f0:af:f0:af" is the device bluetooth address, taken from "phys"
field in struct hid_device due to overflow.)
Cc: stable@vger.kernel.org
Signed-off-by: Anderson Lizardo <anderson.lizardo@openbossa.org>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Recent versions of udev cause synchronous firmware loading from the
probe routine to fail because the request to user space would time
out. The original fix for b43 (commit 6b6fa58) moved the firmware
load from the probe routine to a work queue, but it still used synchronous
firmware loading. This method is OK when b43 is built as a module;
however, it fails when the driver is compiled into the kernel.
This version changes the code to load the initial firmware file
using request_firmware_nowait(). A completion event is used to
hold the work queue until that file is available. This driver
reads several firmware files - the remainder can be read synchronously.
On some test systems, the async read fails; however, a following synch
read works, thus the async failure falls through to the sync try.
Reported-and-Tested by: Felix Janda <felix.janda@posteo.de>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> (V3.4+)
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The fields must be null-terminated, or simple_strtoul will cause issue.
Signed-off-by: Chen Gang <gang.chen@asianux.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Do not dereference p->station_id after kfree(cmd) because p
points into the cmd data structure.
Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Julian Wollrath <jwollrath@web.de>
Acked-by: Larry Finger <Larry.finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This adds support for the 60 GHz 802.11ad Wilocity card
through a new driver, wil6210. Wilocity implemented the
firmware, QCA maintains the device driver.
Currently supported:
- STA: with security
- AP: limited to 1 connected STA, security disabled
- Monitor: due to a hardware/firmware limitation
either control or non-control frames are monitored
Using a STA and AP with this drive, one can assemble
a fully functional BSS. Throughput of 1.2Gbps is achieved
with iperf.
The wil6210 cards have on-board flash memory for the
firmware, the cards comes pre-flashed and no firmware
download is required.
For more details see:
http://wireless.kernel.org/en/users/Drivers/wil6210
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
wait_event_interruptible function returns -ERESTARTSYS if it's
interrupted by a signal. Driver should check the return value
and handle this case properly.
In mwifiex_wait_queue_complete() routine, as we are now checking
wait_event_interruptible return value, the condition check is not
required. Also, we have removed mwifiex_cancel_pending_ioctl()
call to avoid a chance of sending second command to FW by other path
as soon as we clear current command node. FW can not handle two
commands simultaneously.
Cc: "3.6+" <stable@vger.kernel.org>
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>
Ath9k consists of 2 different sub-modules: ATH9K and ATH9K_HTC.
Both uses common Atheros code from ath.ko and need ATH_COMMON.
However, while ATH9K selects ATH_COMMON, ATH9K_HTC does not.
As result, if ATH9K_HTC is the only Atheros card selected, compilation fails with
unresolved symbols.
This patch moves ATH_COMMON selection to the common part for both
ATH9K and ATH9K_HTC
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There's a bug in the currently released firmware version,
the sequence control in the Tx response isn't updated in
all cases. Take it from the packet as a workaround.
Cc: stable@vger.kernel.org
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
