- Jun 13, 2013
-
-
Gabor Juhos authored
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:
Gabor Juhos <juhosg@openwrt.org> Acked-by:
Stanislaw Gruszka <sgruszka@redhat.com> Acked-by:
Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Gabor Juhos authored
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:
-
Gabor Juhos authored
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:
-
Gabor Juhos authored
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:
-
Gabor Juhos authored
The qdesc parameter is not used anymore, so remove that. Signed-off-by:
-
Gabor Juhos authored
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:
-
Sujith Manoharan authored
Signed-off-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by:
-
Sujith Manoharan authored
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:
-
Sujith Manoharan authored
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:
-
Sujith Manoharan authored
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:
-
Sujith Manoharan authored
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:
-
Sujith Manoharan authored
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:
-
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wirelessJohn W. Linville authored
Conflicts: drivers/net/wireless/ath/ath9k/Kconfig net/mac80211/iface.c
-
- Jun 12, 2013
-
-
Kees Cook authored
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:
Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Signed-off-by:
-
Sujith Manoharan authored
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:
-
Felix Fietkau authored
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:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Sujith Manoharan authored
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:
-
Yijing Wang authored
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:
Yijing 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:
Jingoo Han <jg1.han@samsung.com> Signed-off-by:
-
Larry Finger authored
This false leak indication is avoided with a no-leak annotation to kmemleak. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Eliad Peller authored
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:
Eliad Peller <eliad@wizery.com> Signed-off-by:
Luciano Coelho <coelho@ti.com> Signed-off-by:
-
Luciano Coelho authored
The minimum firmware version required for singlerole after recent driver changes is 6/7.3.10.0.133. Reported-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Luciano Coelho authored
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:
Levi Pearson <levipearson@gmail.com> Reported-by:
Michael Scott <hashcode0f@gmail.com> Cc: stable@kernel.org # 3.9+ Signed-off-by:
-
Larry Finger authored
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:
-
Mark A. Greer authored
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:
Mark A. Greer <mgreer@animalcreek.com> Acked-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
-
Johan Hedberg authored
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:
Johan Hedberg <johan.hedberg@intel.com> Cc: stable@vger.kernel.org Acked-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by:
-
Johan Hedberg authored
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:
-
Bing Zhao authored
The register offsets have been changed in SD8897 and newer chips. Define a new btmrvl_sdio_card_reg map for SD88xx. Signed-off-by:
Frank Huang <frankh@marvell.com> Signed-off-by:
-
Johan Hedberg authored
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:
-
Solomon Peachy authored
Signed-off-by:
Solomon Peachy <pizza@shaftnet.org> Signed-off-by:
-
Solomon Peachy authored
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:
-
Solomon Peachy authored
This can live on as an out-of-tree patch for those that care. Signed-off-by:
-
- Jun 11, 2013
-
-
Gabor Juhos authored
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:
Jakub Kicinski <moorray@wp.pl> Signed-off-by:
-
Yunlian Jiang authored
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:Yunlian Jiang <yunlian@google.com> Acked-by:
-
-
Dan Carpenter authored
Check for allocation failures and return -ENOMEM. The caller already expects it. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Dan Carpenter authored
This has only one caller and rates[] is an array with IEEE80211_TX_MAX_RATES (4) elements. Signed-off-by:
-
Solomon Peachy authored
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:
-
Joe Perches authored
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:
Joe Perches <joe@perches.com> Acked-By:
-
- Jun 05, 2013
-
-
Eytan Lifshitz authored
The Thermal Throttling code could do that, fix it. Signed-off-by:
Eytan Lifshitz <eytan.lifshitz@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Emmanuel Grumbach authored
In multicast, there is no retries nor RTS since there is no specific recipient that can ACK or send CTS. This means that we must not use the rate scale table for multicast frames. This true for any frame that doesn't have a valid ieee80211_sta pointer. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
