We want the data stored in "addr" and "qual", but the extra ampersands
mean we are copying stack data instead.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Patch fixes zd1201 not to use stack as URB transfer_buffer. URB buffers need
to be DMA-able, which stack is not.

Patch is only compile tested.

Cc: stable@vger.kernel.org
Signed-off-by: NJussi Kivilinna <jussi.kivilinna@iki.fi>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If scheduling an important time event fails, or if we get
an unexpected notification from the firmware, there isn't
much we can do to recover, so just drop the connection and
let higher layers retry it.
Reviewed-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This reverts commit a53ee0a3.

This fix causes a worse HW Error when entering RF-Kill.
Signed-off-by: NGuy Cohen <guy.cohen@intel.com>
Signed-off-by: NDor Shaish <dor.shaish@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There's an underlying race condition with the unjoin_work() call that is
sometimes triggered depending on scheduling order and the phase of the
moon.  This doesn't fix the race condition, but it does remove the
ill-advised BUG_ON() call in an easily-recoverable situation.
Signed-off-by: NSolomon Peachy <pizza@shaftnet.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Using rfkill switch can make firmware unstable, what cause various
Microcode errors and kernel warnings. Reseting firmware just after
rfkill off (radio on) helped with that.

Resolve:
https://bugzilla.redhat.com/show_bug.cgi?id=977053Reported-and-tested-by: NJustin Pearce <whitefox@guardianfox.net>
Cc: stable@vger.kernel.org
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If device was put into a sleep and system was restarted or module
reloaded, we have to wake device up before sending other commands.
Otherwise it will fail to start with Microcode error.

Cc: stable@vger.kernel.org
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We missed bss_mode check for P2P client.
Signed-off-by: NStone Piao <piaoyun@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>

This patch fixes an issue wherein adhoc rates were being copied
into association request from P2P client.

Cc: <stable@vger.kernel.org> # 3.10.y
Signed-off-by: NAvinash Patil <patila@marvell.com>
Signed-off-by: NStone Piao <piaoyun@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes an issue wherein association would fail on P2P
interfaces. This happened because we are checking priv->mode
against NL80211_IFTYPE_STATION. While this check is correct for
infrastructure stations, it would fail P2P clients for which mode
is NL80211_IFTYPE_P2P_CLIENT.

Better check would be bss_role which has only 2 values: STA/AP.

Cc: <stable@vger.kernel.org> # 3.10.y
Signed-off-by: NAvinash Patil <patila@marvell.com>
Signed-off-by: NStone Piao <piaoyun@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

As Arjan pointed out, we mustn't do anything related to PCI
configuration until the device is properly enabled with
pci_enable_device().

Cc: stable@vger.kernel.org
Reported-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If channel switch is pending and we remove interface we can
crash like showed below due to passing NULL vif to mac80211:

BUG: unable to handle kernel paging request at fffffffffffff8cc
IP: [<ffffffff8130924d>] strnlen+0xd/0x40
Call Trace:
 [<ffffffff8130ad2e>] string.isra.3+0x3e/0xd0
 [<ffffffff8130bf99>] vsnprintf+0x219/0x640
 [<ffffffff8130c481>] vscnprintf+0x11/0x30
 [<ffffffff81061585>] vprintk_emit+0x115/0x4f0
 [<ffffffff81657bd5>] printk+0x61/0x63
 [<ffffffffa048987f>] ieee80211_chswitch_done+0xaf/0xd0 [mac80211]
 [<ffffffffa04e7b34>] iwl_chswitch_done+0x34/0x40 [iwldvm]
 [<ffffffffa04f83c3>] iwlagn_commit_rxon+0x2a3/0xdc0 [iwldvm]
 [<ffffffffa04ebc50>] ? iwlagn_set_rxon_chain+0x180/0x2c0 [iwldvm]
 [<ffffffffa04e5e76>] iwl_set_mode+0x36/0x40 [iwldvm]
 [<ffffffffa04e5f0d>] iwlagn_mac_remove_interface+0x8d/0x1b0 [iwldvm]
 [<ffffffffa0459b3d>] ieee80211_do_stop+0x29d/0x7f0 [mac80211]

This is because we nulify ctx->vif in iwlagn_mac_remove_interface()
before calling some other functions that teardown interface. To fix
just check ctx->vif on iwl_chswitch_done(). We should not call
ieee80211_chswitch_done() as channel switch works were already canceled
by mac80211 in ieee80211_do_stop() -> ieee80211_mgd_stop().

Resolve:
https://bugzilla.redhat.com/show_bug.cgi?id=979581

Cc: stable@vger.kernel.org
Reported-by: NLukasz Jagiello <jagiello.lukasz@gmail.com>
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since we clear QUEUE_STARTED in rt2x00queue_stop_queue(), following
call to rt2x00queue_pause_queue() reduce to noop, i.e we do not
stop queue in mac80211.

To fix that introduce rt2x00queue_pause_queue_nocheck() function,
which will stop queue in mac80211 directly.

Note that rt2x00_start_queue() explicitly set QUEUE_PAUSED bit.

Note also that reordering operations i.e. first call to
rt2x00queue_pause_queue() and then clear QUEUE_STARTED bit, will race
with rt2x00queue_unpause_queue(), so calling ieee80211_stop_queue()
directly is the only available solution to fix the problem without
major rework.

Cc: stable@vger.kernel.org
Signed-off-by: NStanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When the brcmfmac device is physically removed cfg80211 gives a
warning upon unregistering the net device (see below).

[23052.390197] WARNING: CPU: 0 PID: 30 at net/wireless/core.c:937 cfg80211_netdev_notifier_call+0x164/0x600 [cfg80211]()
[23052.400843] Modules linked in: brcmfmac(O) brcmutil(O) cfg80211(O) pl2303 usbserial binfmt_misc snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event lpc_ich snd_seq snd_timer snd_seq_device snd psmouse mfd_core serio_raw soundcore snd_page_alloc intel_ips dell_laptop dell_wmi sparse_keymap dcdbas nouveau ttm drm_kms_helper drm i2c_algo_bit mxm_wmi ahci libahci sdhci_pci firewire_ohci firewire_core sdhci crc_itu_t mmc_core intel_agp intel_gtt e1000e ptp pps_core agpgart video [last unloaded: brcmfmac]
[23052.452987] CPU: 0 PID: 30 Comm: khubd Tainted: G           O 3.11.0-rc1-wl-testing-lockdep-00002-g41cc093-dirty #1
[23052.463480] Hardware name: Dell Inc. Latitude E6410/07XJP9, BIOS A07 02/15/2011
[23052.470852]  00000000 00000000 f4efdc18 c1522e3d f845bed2 f4efdc48 c103fbe4 c16a9254
[23052.478762]  00000000 0000001e f845bed2 000003a9 f841da44 f841da44 f3790004 f25539c0
[23052.486741]  e2700200 f4efdc58 c103fc22 00000009 00000000 f4efdcc0 f841da44 00000002
[23052.494712] Call Trace:
[23052.497165]  [<c1522e3d>] dump_stack+0x4b/0x66
[23052.501685]  [<c103fbe4>] warn_slowpath_common+0x84/0xa0
[23052.507085]  [<f841da44>] ? cfg80211_netdev_notifier_call+0x164/0x600 [cfg80211]
[23052.514542]  [<f841da44>] ? cfg80211_netdev_notifier_call+0x164/0x600 [cfg80211]
[23052.521981]  [<c103fc22>] warn_slowpath_null+0x22/0x30
[23052.527191]  [<f841da44>] cfg80211_netdev_notifier_call+0x164/0x600 [cfg80211]
[23052.534494]  [<c150abe8>] ? packet_notifier+0xc8/0x1d0
[23052.539703]  [<c150abfc>] ? packet_notifier+0xdc/0x1d0
[23052.544880]  [<c150ab20>] ? packet_seq_stop+0x30/0x30
[23052.550002]  [<c152d655>] notifier_call_chain+0x45/0x60
[23052.555298]  [<c106839f>] raw_notifier_call_chain+0x1f/0x30
[23052.560963]  [<c143c693>] call_netdevice_notifiers_info+0x33/0x70
[23052.567153]  [<c1459869>] ? qdisc_destroy+0x99/0xb0
[23052.572116]  [<c143c6e3>] call_netdevice_notifiers+0x13/0x20
[23052.577861]  [<c143df93>] rollback_registered_many+0xf3/0x1d0
[23052.583687]  [<c1524cfc>] ? mutex_lock_nested+0x25c/0x350
[23052.589150]  [<c143e0f4>] rollback_registered+0x24/0x40
[23052.594445]  [<c143e15f>] unregister_netdevice_queue+0x4f/0xb0
[23052.600344]  [<c143e299>] unregister_netdev+0x19/0x30
[23052.605484]  [<f865b38f>] brcmf_del_if+0xbf/0x160 [brcmfmac]
[23052.611223]  [<f865b7ae>] brcmf_detach+0x5e/0xd0 [brcmfmac]
[23052.616881]  [<f8667413>] brcmf_usb_disconnect+0x63/0xa0 [brcmfmac]
[23052.623217]  [<c13e09aa>] usb_unbind_interface+0x4a/0x180

When the device is physically connected the driver sends a disassoc
command to the device and response triggers the driver to inform cfg80211
about it. However, with the device removed the disassoc command fails.
This patch adds a call to cfg80211_disconnected() when that command fails.

The warning was added by commit below and also cleans up, but better
doing it in the driver if only to get rid of the warning.

commit f9bef3df
Author: Ben Greear <greearb@candelatech.com>
Date:   Wed Jun 19 14:06:26 2013 -0700

    wireless: check for dangling wdev->current_bss pointer

Cc: Ben Greear <greearb@candelatech.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>

Both type and pkt_len variables are in host endian and these should be in
Little Endian in the payload.
Signed-off-by: NTomasz Moń <desowin@gmail.com>
Acked-by: NBing Zhao <bzhao@marvell.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If we forget to do so, we can't send HCMD to firmware while
the NIC is in RFKILL state.

Cc: stable@vger.kernel.org
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When a not fully started aggregation session is destroyed
and flushed, we get a warning, e.g.

  WARNING: at drivers/net/wireless/iwlwifi/pcie/tx.c:1142 iwl_trans_pcie_txq_disable+0x11c/0x160
  queue 16 not used
  Modules linked in: [...]
  Pid: 5135, comm: hostapd Tainted: G        W  O 3.5.0 #10
  Call Trace:
  wlan0: driver sets block=0 for sta 00:03:7f:10:44:d3
   [<ffffffff81036492>] warn_slowpath_common+0x72/0xa0
   [<ffffffff81036577>] warn_slowpath_fmt+0x47/0x50
   [<ffffffffa0368d6c>] iwl_trans_pcie_txq_disable+0x11c/0x160 [iwlwifi]
   [<ffffffffa03a2099>] iwl_mvm_sta_tx_agg_flush+0xe9/0x150 [iwlmvm]
   [<ffffffffa0396c43>] iwl_mvm_mac_ampdu_action+0xf3/0x1e0 [iwlmvm]
   [<ffffffffa0293ad3>] ___ieee80211_stop_tx_ba_session+0x193/0x920 [mac80211]
   [<ffffffffa0294ed8>] __ieee80211_stop_tx_ba_session+0x48/0x70 [mac80211]
   [<ffffffffa029159f>] ieee80211_sta_tear_down_BA_sessions+0x4f/0x80 [mac80211]
   [<ffffffffa028a686>] __sta_info_destroy+0x66/0x370 [mac80211]
   [<ffffffffa028abb4>] sta_info_destroy_addr_bss+0x44/0x70 [mac80211]
   [<ffffffffa02a3e26>] ieee80211_del_station+0x26/0x50 [mac80211]
   [<ffffffffa01e6395>] nl80211_del_station+0x85/0x200 [cfg80211]

when a station deauthenticated from us without fully setting
up the aggregation session.

Fix this by checking the aggregation state before removing
the hardware queue.

Cc: stable@vger.kernel.org
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The managed interface PS was not disabled when a GO interface
was added. As a consequence, when the station VMAC was in PS,
the GO also was not on the medium. Fix this.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This allows to clean all kinds of bad state it might be in.
This solves situation where HW RFkill was switched while
the NIC was offline.
Until now, we relied on the firmware to do clean the
interrupt, but new firmwares don't do that any more.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Set SSID bitmap for direct scan even on passive channels,
for the passive-to-active feature. Without this patch only
the SSID from probe request template is sent on passive
channels, after passive-to-active switching, causing us to
not find all desired networks.

Remove the unused passive scan mask constant.

Cc: stable@vger.kernel.org
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Unfortunately, the firmware only supports replay counters for
a single GTK in D3, so that we should only upload the last
key and use its replay counters. Since mac80211 key iteration
will walk through the keys in order of their addition, simply
use the same HW key index (1) for all GTKs, thus overwriting
previous ones with newer ones. The replay counters for it are
already used.
Reviewed-by: NYaron Vaknin <Yaron.Vaknin@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

To avoid ending up in a NULL-pointer access, the function
brcmf_txflowblock_if() should only be called for interfaces
that have a netdev associated with it.
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>

If the transmit fails because there are no hanger slots or
any other reason and the packet was an EAPOL packet the
pending counter should be decreased although it was not
transmitted so the driver does not end up in a dead-lock.
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>

Building driver wil6210 in 3.10 and 3.11 kernels yields the following errors:

  CC [M]  drivers/net/wireless/ath/wil6210/debugfs.o
drivers/net/wireless/ath/wil6210/debugfs.c: In function 'wil_print_ring':
drivers/net/wireless/ath/wil6210/debugfs.c:163:11: error: pointer targets in passing argument 5 of 'hex_dump_to_buffer' differ in signedness [-Werror=pointer-sign]
           false);
           ^
In file included from include/linux/kernel.h:13:0,
                 from include/linux/cache.h:4,
                 from include/linux/time.h:4,
                 from include/linux/stat.h:18,
                 from include/linux/module.h:10,
                 from drivers/net/wireless/ath/wil6210/debugfs.c:17:
include/linux/printk.h:361:13: note: expected 'char *' but argument is of type 'unsigned char *'
 extern void hex_dump_to_buffer(const void *buf, size_t len,
             ^
drivers/net/wireless/ath/wil6210/debugfs.c: In function 'wil_txdesc_debugfs_show':
drivers/net/wireless/ath/wil6210/debugfs.c:429:10: error: pointer targets in passing argument 5 of 'hex_dump_to_buffer' differ in signedness [-Werror=pointer-sign]
          sizeof(printbuf), false);
          ^
In file included from include/linux/kernel.h:13:0,
                 from include/linux/cache.h:4,
                 from include/linux/time.h:4,
                 from include/linux/stat.h:18,
                 from include/linux/module.h:10,
                 from drivers/net/wireless/ath/wil6210/debugfs.c:17:
include/linux/printk.h:361:13: note: expected 'char *' but argument is of type 'unsigned char *'
 extern void hex_dump_to_buffer(const void *buf, size_t len,
             ^
cc1: all warnings being treated as errors
make[5]: *** [drivers/net/wireless/ath/wil6210/debugfs.o] Error 1
make[4]: *** [drivers/net/wireless/ath/wil6210] Error 2
make[3]: *** [drivers/net/wireless/ath] Error 2
make[2]: *** [drivers/net/wireless] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2

These errors are fixed by changing the type of the buffer from "unsigned char *" to "char *".
Reported-by: NThomas Fjellstrom <thomas@fjellstrom.ca>
Tested-by: NThomas Fjellstrom <thomas@fjellstrom.ca>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>  [3.10]
Cc: Thomas Fjellstrom <thomas@fjellstrom.ca>
Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In monitor mode, priv->vif is NULL, but at one point in the receive path we
blindly attempt to dereference it.  Add a test to prevent this.
Signed-off-by: NSolomon Peachy <pizza@shaftnet.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently ath9k_htc will reboot firmware only if interface was
ever started. Which lead to the problem in case where interface
was never started but module need to be reloaded.

This patch will partially fix bug "ath9k_htc: Target is unresponsive"
https://github.com/qca/open-ath9k-htc-firmware/issues/1

Reproduction case:
- plug adapter
- make sure nothing will touch it. Stop Networkmanager or blacklist mac address of this adapter.
- rmmod ath9k_htc; sleep 1; modprobe ath9k_htc
Signed-off-by: NOleksij Rempel <linux@rempel-privat.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: https://github.com/qca/open-ath9k-htc-firmware/issues/1Tested-by: NBo Shi <cnshibo@gmail.com>
Signed-off-by: NOleksij Rempel <linux@rempel-privat.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

During tear down (e.g. mwifiex_sdio_remove during system suspend),
mwifiex left IRQs enabled for a significant period of time when it was
unable to handle them correctly. This caused interrupt storms and
interfered with the bluetooth interface on the same SDIO card.

Solve this by disabling interrupts at the point when they can no longer
be handled correctly, which is at the start of mwifiex_remove_card().

For cleanliness, we now enable interrupts in the mwifiex_add_card() path,
to be symmetrical with the disabling of interrupts. We also couple the
registration of the sdio IRQ handler with the actual enable/disable of
interrupts at the hardware level.

I also removed a write to this register in mwifiex_init_sdio which seemed
pointless and won't cause any ill effects now that we only register
the SDIO IRQ handler when we are ready to accept interrupts.

Includes some corrections from Amitkumar Karwar.
Signed-off-by: NDaniel Drake <dsd@laptop.org>
Acked-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This SKU was missing in the list of supported devices

https://bugzilla.kernel.org/show_bug.cgi?id=60577

Cc: <stable@vger.kernel.org> [all versions]
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If NO_DMA=y:

drivers/built-in.o: In function `ath10k_skb_unmap':
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `ath10k_skb_map':
drivers/net/wireless/ath/ath10k/core.h:83: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath10k/core.h:86: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `ath10k_htt_rx_ring_free':
drivers/net/wireless/ath/ath10k/htt_rx.c:113: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `ath10k_htt_rx_amsdu_pop':
drivers/net/wireless/ath/ath10k/htt_rx.c:296: undefined reference to `dma_unmap_single'
drivers/net/wireless/ath/ath10k/htt_rx.c:389: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `__ath10k_htt_rx_ring_fill_n':
drivers/net/wireless/ath/ath10k/htt_rx.c:146: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath10k/htt_rx.c:150: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `ath10k_htt_rx_attach':
drivers/net/wireless/ath/ath10k/htt_rx.c:474: undefined reference to `dma_alloc_coherent'
drivers/net/wireless/ath/ath10k/htt_rx.c:509: undefined reference to `dma_free_coherent'
drivers/net/wireless/ath/ath10k/htt_rx.c:514: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `ath10k_htt_rx_detach':
drivers/net/wireless/ath/ath10k/htt_rx.c:220: undefined reference to `dma_unmap_single'
drivers/net/wireless/ath/ath10k/htt_rx.c:228: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `ath10k_skb_map':
drivers/net/wireless/ath/ath10k/core.h:83: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath10k/core.h:86: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `ath10k_skb_unmap':
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `ath10k_skb_map':
drivers/net/wireless/ath/ath10k/core.h:83: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath10k/core.h:86: undefined reference to `dma_mapping_error'
drivers/net/wireless/ath/ath10k/core.h:83: undefined reference to `dma_map_single'
drivers/net/wireless/ath/ath10k/core.h:86: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `ath10k_skb_unmap':
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'
drivers/net/wireless/ath/ath10k/core.h:98: undefined reference to `dma_unmap_single'
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-wireless@vger.kernel.org
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

The multicast search bit is disabled for the AR9003
family, but this is required for AR9002 too. Fix this in
the INI override routine.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The present build configuration for the rtlwifi family of drivers will
fail under two known conditions:

(1) If rtlwifi is selected without selecting any of the dependent drivers,
    there are errors in the build.
(2) If the PCI drivers are built into the kernel and the USB drivers are modules,
    or vice versa, there are missing globals.

The first condition is fixed by never building rtlwifi unless at least one
of the device drivers is selected. The second failure is fixed by splitting
the PCI and USB codes out of rtlwifi, and creating their own mini drivers.
If the drivers that use them are modules, they will also be modules.

Although a number of files are touched by this patch, only Makefile and Kconfig
have undergone significant changes. The only modifications to the other files
were to export entry points needed by the new rtl_pci and rtl_usb units, or to
rename two variables that had names that were likely to cause namespace collisions.

Reported-by: Fengguang Wu <fengguang.wu@intel.com>  [Condition 1]
Reported-by: Ben Hutchings <bhutchings@solarflare.com> [Condition 2]
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Ben Hutchings <bhutchings@solarflare.com>
Cc: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Bit 32 was always set which looks to have been accidental,
according to git history.
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If NO_DMA=y:

drivers/built-in.o: In function `rt2x00queue_unmap_skb':
drivers/net/wireless/rt2x00/rt2x00queue.c:129: undefined reference to `dma_unmap_single'
drivers/net/wireless/rt2x00/rt2x00queue.c:133: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `rt2x00queue_map_txskb':
drivers/net/wireless/rt2x00/rt2x00queue.c:112: undefined reference to `dma_map_single'
drivers/net/wireless/rt2x00/rt2x00queue.c:115: undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `rt2x00queue_alloc_rxskb':
drivers/net/wireless/rt2x00/rt2x00queue.c:93: undefined reference to `dma_map_single'
drivers/net/wireless/rt2x00/rt2x00queue.c:95: undefined reference to `dma_mapping_error'
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-wireless@vger.kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ath9k_hif_usb_probe() requests firmware asynchronically and
there is some initialization postponed till firmware is ready.
In particular, ath9k_hif_usb_firmware_cb() callback initializes
hif_dev->tx.tx_buf and hif_dev->tx.tx_pending lists.

At the same time, ath9k_hif_usb_suspend() iterates that lists through
ath9k_hif_usb_dealloc_urbs(). If suspend happens before request_firmware_nowait()
callback is called, it can lead to oops.

Similar issue could be in ath9k_hif_usb_disconnect(), but it is prevented
using hif_dev->fw_done completion and HIF_USB_READY flag. The patch extends
this approach to suspend() as well.

Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When dropping packets that have gone far enough into the tx path, the
pending frame counter needs to be decreased.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Commit a269913c entitled "rtlwifi: Rework rtl_lps_leave() and
rtl_lps_enter() to use work queue" has two bugs for USB drivers.
Firstly, the work queue in question was not initialized. Secondly,
the callback routine used by this queue is contained within the
file used for PCI devices. As a result, it is not available for
architectures without PCI hardware.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Reported-by: NRichard Genoud <richard.genoud@gmail.com>
Tested-by: NRichard Genoud <richard.genoud@gmail.com>
Cc: Richard Genoud <richard.genoud@gmail.com>
Cc: Stable <stable@vger.kernel.org> [3.10]
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Bits 1-21 in this channel type attributes are indication for which
SSID is going to be sent on this channel. Since the first SSID is
sent implicitly in the probe request, we don't need to toggle its
bit here.
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Increment index in each iteration. Without this increment we are
overriding the added SSIDs and we will send only the last SSId
and (n_ssids - 1) broadcast probes.

Cc: <stable@vger.kernel.org> [3.9+]
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Due to a firmware bug, it crashes when the beacon interval
is smaller than 16. Avoid this by refusing the station state
change creating the AP station, causing mac80211 to abandon
the attempt to connect to the AP, and eventually wpa_s to
blacklist it.

Cc: stable@vger.kernel.org
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>