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.

Cc: stable@vger.kernel.org
Reported-by: NAntonio Quartulli <antonio@open-mesh.com>
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In AP mode, configure the fw to pass beacons from
foreign APs, in order to be able to set the ht
protection IE properly.

Add the same filters in case of GO (which didn't have
any configured filter_flags, probably by mistake)
Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Function rt2800usb_autorun_detect() passes the address of a variable
allocated onto the stack to be used for DMA by the USB layer. This has
been caught by my debugging-enabled kernel.

This patch change things in order to allocate that variable via
kmalloc, and it adjusts things to handle the kmalloc failure case,
propagating the error.

[ 7363.238852] ------------[ cut here ]------------
[ 7363.243529] WARNING: CPU: 1 PID: 5235 at lib/dma-debug.c:1153 check_for_stack+0xa4/0xf0()
[ 7363.251759] ehci-pci 0000:00:04.1: DMA-API: device driver maps memory fromstack [addr=ffff88006b81bad4]
[ 7363.261210] Modules linked in: rt2800usb(O+) rt2800lib(O) rt2x00usb(O) rt2x00lib(O) rtl818x_pci(O) rtl8187 led_class eeprom_93cx6 mac80211 cfg80211 [last unloaded: rt2x00lib]
[ 7363.277143] CPU: 1 PID: 5235 Comm: systemd-udevd Tainted: G           O  3.16.0-rc3-wl+ #31
[ 7363.285546] Hardware name: System manufacturer System Product Name/M3N78 PRO, BIOS ASUS M3N78 PRO ACPI BIOS Revision 1402 12/04/2009
[ 7363.297511]  0000000000000009 ffff88006b81b710 ffffffff8175dcad ffff88006b81b758
[ 7363.305062]  ffff88006b81b748 ffffffff8106d372 ffff88006cf10098 ffff88006cead6a0
[ 7363.312622]  ffff88006b81bad4 ffffffff81c1e7c0 ffff88006cf10098 ffff88006b81b7a8
[ 7363.320161] Call Trace:
[ 7363.322661]  [<ffffffff8175dcad>] dump_stack+0x4d/0x6f
[ 7363.327847]  [<ffffffff8106d372>] warn_slowpath_common+0x82/0xb0
[ 7363.333893]  [<ffffffff8106d3e7>] warn_slowpath_fmt+0x47/0x50
[ 7363.339686]  [<ffffffff813a93b4>] check_for_stack+0xa4/0xf0
[ 7363.345298]  [<ffffffff813a995c>] debug_dma_map_page+0x10c/0x150
[ 7363.351367]  [<ffffffff81521bd9>] usb_hcd_map_urb_for_dma+0x229/0x720
[ 7363.357890]  [<ffffffff8152256d>] usb_hcd_submit_urb+0x2fd/0x930
[ 7363.363929]  [<ffffffff810eac31>] ? irq_work_queue+0x71/0xd0
[ 7363.369617]  [<ffffffff810ab5a7>] ? wake_up_klogd+0x37/0x50
[ 7363.375219]  [<ffffffff810ab7a5>] ? console_unlock+0x1e5/0x420
[ 7363.381081]  [<ffffffff810abc25>] ? vprintk_emit+0x245/0x530
[ 7363.386773]  [<ffffffff81523d3c>] usb_submit_urb+0x30c/0x580
[ 7363.392462]  [<ffffffff81524295>] usb_start_wait_urb+0x65/0xf0
[ 7363.398325]  [<ffffffff815243ed>] usb_control_msg+0xcd/0x110
[ 7363.404014]  [<ffffffffa005514d>] rt2x00usb_vendor_request+0xbd/0x170 [rt2x00usb]
[ 7363.411544]  [<ffffffffa0074292>] rt2800usb_autorun_detect+0x32/0x50 [rt2800usb]
[ 7363.418986]  [<ffffffffa0074aa1>] rt2800usb_read_eeprom+0x11/0x70 [rt2800usb]
[ 7363.426168]  [<ffffffffa0063ffd>] rt2800_probe_hw+0x11d/0xf90 [rt2800lib]
[ 7363.432989]  [<ffffffffa0074b7d>] rt2800usb_probe_hw+0xd/0x50 [rt2800usb]
[ 7363.439808]  [<ffffffffa00453d8>] rt2x00lib_probe_dev+0x238/0x7c0 [rt2x00lib]
[ 7363.446992]  [<ffffffffa00bfa48>] ? ieee80211_led_names+0xb8/0x100 [mac80211]
[ 7363.454156]  [<ffffffffa0056116>] rt2x00usb_probe+0x156/0x1f0 [rt2x00usb]
[ 7363.460971]  [<ffffffffa0074250>] rt2800usb_probe+0x10/0x20 [rt2800usb]
[ 7363.467616]  [<ffffffff8152799e>] usb_probe_interface+0xce/0x1c0
[ 7363.473651]  [<ffffffff81480c20>] really_probe+0x70/0x240
[ 7363.479079]  [<ffffffff81480f01>] __driver_attach+0xa1/0xb0
[ 7363.484682]  [<ffffffff81480e60>] ? __device_attach+0x70/0x70
[ 7363.490461]  [<ffffffff8147eef3>] bus_for_each_dev+0x63/0xa0
[ 7363.496146]  [<ffffffff814807c9>] driver_attach+0x19/0x20
[ 7363.501570]  [<ffffffff81480468>] bus_add_driver+0x178/0x220
[ 7363.507270]  [<ffffffff8148151b>] driver_register+0x5b/0xe0
[ 7363.512874]  [<ffffffff815271b0>] usb_register_driver+0xa0/0x170
[ 7363.518905]  [<ffffffffa007a000>] ? 0xffffffffa0079fff
[ 7363.524074]  [<ffffffffa007a01e>] rt2800usb_driver_init+0x1e/0x20 [rt2800usb]
[ 7363.531247]  [<ffffffff810002d4>] do_one_initcall+0x84/0x1b0
[ 7363.536932]  [<ffffffff8113aa60>] ? kfree+0xd0/0x110
[ 7363.541931]  [<ffffffff8112730a>] ? __vunmap+0xaa/0xf0
[ 7363.547538]  [<ffffffff810ca07e>] load_module+0x1aee/0x2040
[ 7363.553141]  [<ffffffff810c6f10>] ? store_uevent+0x50/0x50
[ 7363.558676]  [<ffffffff810ca66e>] SyS_init_module+0x9e/0xc0
[ 7363.564285]  [<ffffffff81764012>] system_call_fastpath+0x16/0x1b
[ 7363.570338] ---[ end trace 01ef5f822bea9882 ]---
Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

There are few places at the begining of Tx/Rx paths where
tx_info/rx_info is not correctly initialized. This patch
takes care of it.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NAvinash Patil <patila@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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.

Cc: <stable@vger.kernel.org> [3.13+]
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

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.

CC: <stable@vger.kernel.org>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The function brcmf_usb_dlneeded() queries the device to obtain the chip
id and revision. So assigning these in bus interface before the call
resulted in chip id and revision being zero. This was introduced by:

   commit 5b8045d4
   Author: Arend van Spriel <arend@broadcom.com>
   Date:   Tue May 27 12:56:23 2014 +0200

       brcmfmac: use asynchronous firmware request in USB
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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.

Cc: <stable@vger.kernel.org>
Reported-by: NAndrew Wiley <wiley.andrew.j@gmail.com>
Reported-by: NLinus Gasser <list@markas-al-nour.org>
Reported-by: NMichael Hirsch <hirsch@teufel.de>
Tested-by: NXinming Hu <huxm@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NMaithili Hinge <maithili@marvell.com>
Signed-off-by: NAvinash Patil <patila@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Current code did not allow sending the broadcast filtering command
for P2P Client interfaces. However, this was not enough, since once
broadcast filtering command was issued over the station interface
after the P2P Client connected, the command also attached the filters
to the P2P Client MAC which is not allowed (FW ASSERT 1063).

Fix this skipping P2P Client interfaces when constructing the broadcast
filtering command
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Reviewed-by: NArikX Nemtsov <arik@wizery.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This reverts commit dc9a1929.

3610 cards don't support UAPSD.
Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Add one more 7265 series HW ID.
Edit one existing 7265 series HW ID.

CC: <stable@vger.kernel.org> [3.13+]
Signed-off-by: NOren Givon <oren.givon@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The current sched scan channel configuration code
configures all the supported channels for scanning.

However, this can result in SYSASSERT in some cases,
when the configured channel is disabled.

Instead, configure only the channels given in the
req struct, and set the channel_count field appropriately.

While on it, change the code to use channel->hw_value
instead of recalculating the channel number.
Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

As reported by Niels, starting rfkill polling during device probe
(commit e2bc7c5f, 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: e2bc7c5f ("rt2x00: Fix rfkill_polling register function.")
Cc: stable@vger.kernel.org
Bisected-by: NNiels <nille0386@googlemail.com>
Reported-and-tested-by: NNiels <nille0386@googlemail.com>
Signed-off-by: NStanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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 3afc2167
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: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Cc: stable@vger.kernel.org
Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The device 057c:8501 (AVM Fritz! WLAN v2 rev. B) boots into a state that does
not actually require loading a firmware file. The vendors driver finds out
about this by checking a firmware state register, so this patch adds this here.

Finally, with this patch applied, my wifi dongle actually becomes
useful (scan + connect to wpa network works).
Signed-off-by: NMichael Braun <michael-dev@fami-braun.de>
Acked-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The device 057c:8501 (AVM Fritz! WLAN v2 rev. B) currently does not
load. One thing observed is that the vendors driver detects EFUSE mode
for this device, but rt2800usb does not. This is due to rt2800usb
lacking a check for the firmware mode present in the vendors driver,
that this patch adopts for rt2800usb.

With this patch applied, the 'RF chipset' detection does no longer fail.
Signed-off-by: NMichael Braun <michael-dev@fami-braun.de>
Acked-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Reported-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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]

Cc: stable@vger.kernel.org
Reported-and-tested-by: NPeter Wu <lekensteyn@gmail.com>
Reported-and-tested-by: NPontus Fuchs <pontus.fuchs@gmail.com>
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On PCIe Tx data path, network interface specific tx_info
parameters such as bss_num and bss_type are saved at
"skb->cb + sizeof(dma_addr_t)" (returned by MWIFIEX_SKB_TXCB).
Later mwifiex_map_pci_memory() called from
mwifiex_pcie_send_data() will memcpy
sizeof(struct mwifiex_dma_mapping) bytes to save PCIe DMA
address and length information at beginning of skb->cb.
This accidently overwrites bss_num and bss_type saved in skb->cb
previously because bss_num/bss_type and mwifiex_dma_mapping data
overlap.
Similarly, on PCIe Rx data path, rx_info parameters overlaps
with PCIe DMA address and length information too.

Fix it by defining mwifiex_cb structure and having
MWIFIEX_SKB_TXCB and MWIFIEX_SKB_RXCB return the correct address
of tx_info/rx_info using the structure members.

Also add a BUILD_BUG_ON to maks sure that mwifiex_cb structure
doesn't exceed the size of skb->cb.
Reviewed-by: NAaron Durbin <adurbin@chromium.org>
Signed-off-by: NChin-Ran Lo <crlo@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This fixes regression introduced by adding some G-PHY devices to the
list of dual band devices. There is simply no support for 5 GHz on
G-PHY devices in b43. It results in:
WARNING: CPU: 0 PID: 79 at drivers/net/wireless/b43/phy_g.c:75 b43_gphy_channel_switch+0x125/0x130 [b43]()
b43-phy1 ERROR: PHY init: Channel switch to default failed

Regression was introduced by the following commit:

commit 773cfc50
Author: Rafał Miłecki <zajec5@gmail.com>
Date:   Mon May 19 23:18:55 2014 +0200

    b43: add more devices to the bands database
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

since commit 3afc2167 scan in not
working anymore, due to mac80211 requires rx frequency status
information.

This patch makes the driver report this information.

While NOT scanning this is straightforward.
While scanning the firmware performs RF sweep and we cannot track
the actual tuning frequency, so this is guessed by parsing beacons
and probe responses.
This should be enough for ensuring functionality.

Thanks-to: Johannes Berg <johannes@sipsolutions.net> [ for suggestions and reviewing ]
Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Firmware 10.x supports up to 8 virtual AP interfaces, but in a DFS
channel it was possible to create only 7 interfaces as ath10k internal
creates a monitor interface for DFS. Previous vdev map initialization
was missing enough space for 8 + 1 vdevs due to wrong define used and
that's why there was no space for 8th interface. Use the correct define
TARGET_10X_NUM_VDEVS with 10.x firmware to make it possible to create
the 8th virtual interface.
Signed-off-by: NBartosz Markowski <bartosz.markowski@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

While fixing a bug reported by Avery I went ahead
and added a warning suspecting there might be
something more to the bug. This ended up with
people reporting they see warnings during heavy
traffic. This bought me some time and helped me
understand the problem better - apparently fw/hw
can report a chained msdus as follows: 1 msdu, 1
chained, 1 msdu (0 length).

The patch removes the extra check but leaves the
other change that fixed the original skb_push
panic bug (msdu_chaining was overwritten in an
unfortunate way which made the above example to
be treated as non-chained case).
Reported-by: NYeoh Chun-Yeow <yeohchunyeow@gmail.com>
Reported-by: NTim Harvey <tharvey@gateworks.com>
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Print message if no events received. This should not happen.
If it is, it points to the problem in firmware.
Track also cases when multiple events processed in one IRQ

Print information as soon as possible - mbox pointers and
event header right after reading it. This helps to identify potential
problem with memory allocation for the event buffer.
Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Now that the config option is gone, the driver needs to be converted
over to using the dynamic_debug infrastructure, like all other USB
drivers have been already.

Cc: Christian Lamparter <chunkeey@googlemail.com>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Gertjan van Wingerde <gwingerde@gmail.com>
Cc: Alexey Khoroshilov <khoroshilov@ispras.ru>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NJohn W. Linville <linville@tuxdriver.com>

A check for CONFIG_AUTOSUSPEND was included in this driver when it was
added in v2.6.39. But that Kconfig symbol doesn't exist. Remove that
check and the single line it hides.
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

fw_common.h was included twice.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

phy.h was included twice.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently mac80211 does not support WDS and DFS with channel context
drivers. So advertise these features only when the driver is not
supporting channel context and modparam "use_chanctx" is introduced
for preparing channel context support in ath9k.
Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If host sleep parameter gap is set to 0xff, firmware will wait
for an ack from host to confirm the success of host wakeup.
This prevents firmware from uploading data packet before host
actually wakes up.
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Current implementation sets tdls_link flag only while restoring
packets from TDLS queue. If traffic to peer starts after TDLS is
setup, there is no way to set TDLS link flag to true. Do this
while creating RA list and we confirm that there exist a TDLS
peer for which setup is complete.
Signed-off-by: NAvinash Patil <patila@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

[113.967694] Unable to handle kernel NULL pointer dereference
               at virtual address 00000020
............
[113.967859] PC is at mwifiex_update_rxreor_flags+0xfc/0x430
............
[113.968110] mwifiex_update_rxreor_flags+0xfc/0x430
[113.968129] mwifiex_handle_event_ext_scan_report+0x1e4/0x21c
[113.968148] mwifiex_process_sta_event+0x410/0x508
[113.968165] mwifiex_process_event+0x184/0x1e0
[113.968181] mwifiex_main_process+0x220/0x48c
[113.968197] mwifiex_sdio_interrupt+0xc8/0x1cc
[113.968210] sdio_irq_thread+0x11c/0x290

In case of legacy scan, adapter->curr_cmd is guranteed to be
non-NULL in check_next_scan_cmd. This may not be case in
extended scan where scan command response would come earlier and
set curr_cmd to NULL. Extended scan event comes later and while
trying to complete IOCTL for scan, driver would crash in
dereferencing adapter->curr_cmd->wait_q_enabled.

Avoid this by completing IOCTL in case of legacy scans only.
Internal scan would be completed while handling extended scan
command response.
Signed-off-by: NAvinash Patil <patila@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Broadcom's wl 6.30.223.141 has some optimizations for radios 0x205[67].
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

PHY has to be often re-initialized (e.g. during band switching after PHY
reset), however some operations have to be performed only once (only
power reset affects them).
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In case of receiving frame with sequence number far greater than current,
wil_release_reorder_frames() will iterate many times over empty buffer.

Optimize this case by checking buffer emptiness and simply update
head_seq_num without iterating.
Suggested-by: NVladimir Shulman <Vladimir.Shulman@Wilocity.com>
Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

use proper format %pad for the dma_addr_t arguments;
prefix %p with 0x, as %p don't print is by itself
Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If scan has not finished in some reasonable time (10sec), interpret it as
if firmware error occurs but was not reported. Firmware should report
scan completion for every scan request, so it is error condition indeed.
Perform firmware recovery procedure.
Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Provide clear definition of the watermarks for the vring descriptor space.
Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>