The generic rt2x00 code has been changed to allow the
drivers toimplement dynamic data_queue initialization.

Remove the static data queue descriptor structures
and implement the queue_init callback instead.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Acked-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The generic rt2x00 code has been changed to allow the
drivers toimplement dynamic data_queue initialization.

Remove the static data queue descriptor structures
and implement the queue_init callback instead.

The actual chipset is already known when the callback
is used. This allows us to use a single callback for
all supported devices.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Acked-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The driver uses static data structures for initializing
specific fields of a given data queue. These static
queue data descriptor structures are containing values
which related to a given chipset.

Even though the values are chip specific, the actual
selection of the used structure is based on device
specific vendor/product identifiers. This approach works,
but it is not always reliable. Sometimes the vendor and/or
device IDs of the PCI and USB devices contains improper
values which makes it impossible to select the correct
structure for such devices.

The patch adds a new callback to tr2x00_ops which
is called after the chipset detection is finished.
This allows the drivers to do dynamic initialization
of the data_queue structure for a given queue based
on the actual chipset.

After each driver implements the queue_init callback,
the data_queue_desc structure will be removed.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Acked-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use the queue->limit value instead of the
qdesc->entry_num to compute the threshold.
The two source values are the same and the
data queue descriptor structure will be
removed by a later patch.

Also separate the computation from the rest
of the init code to make further changes
easier.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Acked-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The beacon data queue is initialized already,
so fetch the number of the queue entries from
that instead of using the entry_num field of
the data queue descriptor.

The two values are the same, and the use of the
rt2x00dev->bcn->limit value allows us to get rid
of a superfluous pointer dereference.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Acked-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The qdesc parameter is not used anymore, so remove that.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Acked-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add a new field into struct data_queue and store
the size of the per-queue_entry private data in
that. Additionally, use the new field in the
rt2x00queue_alloc_entries function to compute
the size of the queue entries for a given queue.

The patch does not change the current behaviour
but makes it possible to remove the queue_desc
parameter of the rt2x00queue_alloc_entries function.
That will be done by a subsequent patch.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Acked-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The phy error mask registers are programmed already
in ath9k_ani_restart(), so there is no need to set them
in ath9k_ani_reset().
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The commit, "ath9k_hw: improve ANI processing and rx desensitizing parameters"
removed code setting various phy registers holding threshold values.

This is likely required for OFDM weak signal detection to function
correctly, so add them, but skip AR9462 and AR9565.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The commit, "ath9k_hw: improve ANI processing and rx desensitizing parameters"
modified the immunity level tables for both CCK and OFDM. Fix them
so that the tables are in sync with the internal driver/codebase.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The commit "ath9k_hw: improve ANI processing and rx desensitizing parameters"
changed various ANI operational parameters to address a specific
card/environment. This is not really applicable for other cards
in general usage.

As per internal documentation, lowering the immunity level can be
done only after 5 periods have passed and the CCK/OFDM errors are
below the low watermak threshold - which have been fixed at 300 and
400 respectively by the sytems team.

Raising the immunity level can be done when CCK/OFDM errors exceed
600 and 1000 (per second).

Set these values once during attach.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The commit "ath9k_hw: improve ANI processing and rx desensitizing parameters"
changed the OFDM weak signal detection logic to disable it
for AP mode, which is not allowed. Fix this and enable it always
for AP mode.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Conflicts:
	drivers/net/wireless/ath/ath9k/Kconfig
	net/mac80211/iface.c

The module parameter "fwpostfix" is userspace controllable, unfiltered,
and is used to define the firmware filename. b43_do_request_fw() populates
ctx->errors[] on error, containing the firmware filename. b43err()
parses its arguments as a format string. For systems with b43 hardware,
this could lead to a uid-0 to ring-0 escalation.

CVE-2013-2852
Signed-off-by: NKees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The ath9k rate control algorithm has various architectural
issues that make it a poor fit in scenarios like congested
environments etc.

An example: https://bugzilla.redhat.com/show_bug.cgi?id=927191

Change the default to minstrel which is more robust in such cases.
The ath9k RC code is left in the driver for now, maybe it can
be removed altogether later on.

Cc: stable@vger.kernel.org
Cc: Jouni Malinen <jouni@qca.qualcomm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This reverts commit 68d9e1fa

This change reduces rx sensitivity with no apparent extra benefit.
It looks like it was meant for testing in a specific scenario,
but it was never properly validated.

Cc: rmanohar@qca.qualcomm.com
Cc: stable@vger.kernel.org
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Almost all the DMA issues which have plagued ath9k (in station mode)
for years are related to PS. Disabling PS usually "fixes" the user's
connection stablility. Reports of DMA problems are still trickling in
and are sitting in the kernel bugzilla. Until the PS code in ath9k is
given a thorough review, disbale it by default. The slight increase
in chip power consumption is a small price to pay for improved link
stability.

Cc: stable@vger.kernel.org
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix build error for il_pm_ops if CONFIG_PM is set
but CONFIG_PM_SLEEP is not set.

ERROR: "il_pm_ops" [drivers/net/wireless/iwlegacy/iwl4965.ko] undefined!
ERROR: "il_pm_ops" [drivers/net/wireless/iwlegacy/iwl3945.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: netdev@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: Jingoo Han <jg1.han@samsung.com>
Acked-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This false leak indication is avoided with a no-leak annotation to kmemleak.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Due to a typo, the current code copies only sizeof(cmd->channels_2)
bytes, which is smaller than the correct sizeof(cmd->channels_5)
size, resulting in a partial scan (some channels are skipped).
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The minimum firmware version required for singlerole after recent
driver changes is 6/7.3.10.0.133.
Reported-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There was a typo in commit 8675f9 (wlcore/wl12xx/wl18xx: verify
multi-role and single-role fw versions), which was causing the
multirole firmware for wl127x (WiLink6) to be rejected.  The actual
minimum version needed for wl127x multirole is 6.5.7.0.42.
Reported-by: NLevi Pearson <levipearson@gmail.com>
Reported-by: NMichael Scott <hashcode0f@gmail.com>
Cc: stable@kernel.org # 3.9+
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Driver rtl8192cu can connect to WPA2 networks, but fails for any other
encryption method. The cause is a failure to set the rate control data
blocks. These changes fix https://bugzilla.redhat.com/show_bug.cgi?id=952793
and https://bugzilla.redhat.com/show_bug.cgi?id=761525.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When reading the contents of '/sys/kernel/debug/mwifiex/p2p0/info',
the following panic occurs:

$ cat /sys/kernel/debug/mwifiex/p2p0/info
Unable to handle kernel paging request at virtual address 74706164
pgd = de530000
[74706164] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in: phy_twl4030_usb omap2430 musb_hdrc mwifiex_sdio mwifiex
CPU: 0 PID: 1635 Comm: cat Not tainted 3.10.0-rc1-00010-g1268390 #1
task: de16b6c0 ti: de048000 task.ti: de048000
PC is at strnlen+0xc/0x4c
LR is at string+0x3c/0xf8
pc : [<c02c123c>]    lr : [<c02c2d1c>]    psr: a0000013
sp : de049e10  ip : c06efba0  fp : de6d2092
r10: bf01a260  r9 : ffffffff  r8 : 74706164
r7 : 0000ffff  r6 : ffffffff  r5 : de6d209c  r4 : 00000000
r3 : ff0a0004  r2 : 74706164  r1 : ffffffff  r0 : 74706164
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 9e530019  DAC: 00000015
Process cat (pid: 1635, stack limit = 0xde048240)
Stack: (0xde049e10 to 0xde04a000)
9e00:                                     de6d2092 00000002 bf01a25e de6d209c
9e20: de049e80 c02c438c 0000000a ff0a0004 ffffffff 00000000 00000000 de049e48
9e40: 00000000 2192df6d ff0a0004 ffffffff 00000000 de6d2092 de049ef8 bef3cc00
9e60: de6b0000 dc358000 de6d2000 00000000 00000003 c02c45a4 bf01790c bf01a254
9e80: 74706164 bf018698 00000000 de59c3c0 de048000 de049f80 00001000 bef3cc00
9ea0: 00000008 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9ec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9ee0: 00000000 00000000 00000000 00000001 00000000 00000000 6669776d 20786569
9f00: 20302e31 2e343128 392e3636 3231702e 00202933 00000000 00000003 c0294898
9f20: 00000000 00000000 00000000 00000000 de59c3c0 c0107c04 de554000 de59c3c0
9f40: 00001000 bef3cc00 de049f80 bef3cc00 de049f80 00000000 00000003 c0108a00
9f60: de048000 de59c3c0 00000000 00000000 de59c3c0 00001000 bef3cc00 c0108b60
9f80: 00000000 00000000 00001000 bef3cc00 00000003 00000003 c0014128 de048000
9fa0: 00000000 c0013f80 00001000 bef3cc00 00000003 bef3cc00 00001000 00000000
9fc0: 00001000 bef3cc00 00000003 00000003 00000001 00000001 00000001 00000003
9fe0: 00000000 bef3cbdc 00011984 b6f1127c 60000010 00000003 18dbdd2c 7f7bfffd
[<c02c123c>] (strnlen+0xc/0x4c) from [<c02c2d1c>] (string+0x3c/0xf8)
[<c02c2d1c>] (string+0x3c/0xf8) from [<c02c438c>] (vsnprintf+0x1e8/0x3e8)
[<c02c438c>] (vsnprintf+0x1e8/0x3e8) from [<c02c45a4>] (sprintf+0x18/0x24)
[<c02c45a4>] (sprintf+0x18/0x24) from [<bf01790c>] (mwifiex_info_read+0xfc/0x3e8 [mwifiex])
[<bf01790c>] (mwifiex_info_read+0xfc/0x3e8 [mwifiex]) from [<c0108a00>] (vfs_read+0xb0/0x144)
[<c0108a00>] (vfs_read+0xb0/0x144) from [<c0108b60>] (SyS_read+0x44/0x70)
[<c0108b60>] (SyS_read+0x44/0x70) from [<c0013f80>] (ret_fast_syscall+0x0/0x30)
Code: e12fff1e e3510000 e1a02000 0a00000d (e5d03000)
---[ end trace ca98273dc605a04f ]---

The panic is caused by the mwifiex_info_read() routine assuming that
there can only be four modes (0-3) which is an invalid assumption.
For example, when testing P2P, the mode is '8' (P2P_CLIENT) so the
code accesses data beyond the bounds of the bss_modes[] array which
causes the panic.  Fix this by updating bss_modes[] to support the
current list of modes and adding a check to prevent the out-of-bounds
access from occuring in the future when more modes are added.
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
Acked-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If hci_dev_open fails we need to ensure that the corresponding
mgmt_set_powered command gets an appropriate response. This patch fixes
the missing response by adding a new mgmt_set_powered_failed function
that's used to indicate a power on failure to mgmt. Since a situation
with the device being rfkilled may require special handling in user
space the patch uses a new dedicated mgmt status code for this.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Cc: stable@vger.kernel.org
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There has been code in place to check that the L2CAP length header
matches the amount of data received, but many PDU handlers have not been
checking that the data received actually matches that expected by the
specific PDU. This patch adds passing the length header to the specific
handler functions and ensures that those functions fail cleanly in the
case of an incorrect amount of data.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The register offsets have been changed in SD8897 and newer chips.
Define a new btmrvl_sdio_card_reg map for SD88xx.
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NFrank Huang <frankh@marvell.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

LE-only controllers do not support extended features so any kind of host
feature bit checks do not make sense for them. This patch fixes code
used for both single-mode (LE-only) and dual-mode (BR/EDR/LE) to use the
HCI_LE_ENABLED flag instead of the "Host LE supported" feature bit for
LE support tests.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NSolomon Peachy <pizza@shaftnet.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is only really useful for people who are bringing up new hardware
designs and have access to the proprietary vendor tools that interface
with this mode.

It'll live out of tree until it's rewritten to use a less kludgy interface.
Signed-off-by: NSolomon Peachy <pizza@shaftnet.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This can live on as an out-of-tree patch for those that care.
Signed-off-by: NSolomon Peachy <pizza@shaftnet.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Support for rt2800 device is broken since my
'rt2x00: rt2x00dev: use rt2x00dev->tx->limit'
patch. The changelog of that commit says that the
TX data queue is initialized already when the
rt2x00lib_probe_hw() function is called.

However as Jakub noticed it, this statement is not
correct. The queue->limit field is initialized in
the rt2x00queue_alloc_entries routine and that is
not yet called when rt2x00lib_probe_hw() runs.
Because the value of tx->limit contains zero, the
driver tries to allocate a kernel fifo with zero
size and kfifo_alloc rejects that with -EINVAL.

  PCI: Enabling device 0000:01:00.0 (0000 -> 0002)
  ieee80211 phy1: rt2x00_set_rt: Info - RT chipset 3071, rev 021c detected
  ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 0008 detected
  ieee80211 phy1: rt2x00lib_probe_dev: Error - Failed to initialize hw
  rt2800pci: probe of 0000:01:00.0 failed with error -22

Move the data_queue field initialization from
the rt2x00queue_alloc_entries routine into the
rt2x00queue_init function. The initialization
code is not strictly related to the allocation,
and the change ensures that the queue_data fields
can be used in the probe routines.

The patch also introduces a helper function in
order to be able to get the correct data_queue_desc
structure for a given queue. This helper is only
needed temporarily and it will be removed later.
Reported-by: NJakub Kicinski <moorray@wp.pl>
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

GCC 4.8 is spitting out uninitialized-variable warnings against
"drivers/net/wireless/rtlwifi/rtl8192de/dm.c".

drivers/net/wireless/rtlwifi/rtl8192de/dm.c:941:31:
error: 'ofdm_index_old[1]' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
     rtlpriv->dm.ofdm_index[i] = ofdm_index_old[i];

This patch adds initialization to the variable and properly sets its value.
Signed-off-by: NYunlian Jiang <yunlian@google.com>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Check for allocation failures and return -ENOMEM.  The caller
already expects it.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This has only one caller and rates[] is an array with
IEEE80211_TX_MAX_RATES (4) elements.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The optional debugfs interface to the vendor's engineering tools wasn't
bounds checking at all, which made it trivial to perform a buffer
overflow if this interface was compiled in and then explicitly enabled
at runtime.

This patch checks both the length supplied as part of the data to ensure
it is sane, and also the amount of data compared to the remaining buffer
space.  If either is too large, fail immediately.

(This bug was spotted by Dan Carpenter <dan.carpenter@oracle.com>)
Signed-off-by: NSolomon Peachy <pizza@shaftnet.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

goto after return is wrong.

The other code in this block needs to set an
error value then goto an error release block.

This one doesn't need to release anything and
was likely a copy/paste remainder.
Signed-off-by: NJoe Perches <joe@perches.com>
Acked-By: NSolomon Peachy <pizza@shaftnet.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The Thermal Throttling code could do that, fix it.
Signed-off-by: NEytan Lifshitz <eytan.lifshitz@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>