- Jul 02, 2014
-
-
Andrea Merello authored
Currently the driver configures mac80211 to provide two rates for each TX frame: One initial rate and one alternate fallback rate, each one with its retry count. HW does not support fully this: rtl8180 doesn't have support for rate scaling at all, and rtl8185/rtl8187SE supports it in a way that does not fit with mac80211: The HW does automatically fall back to the next lower rate, and only a lower limit can be specified, so the HW may TX also on rates in between the two rates specified by mac80211. Furthermore only the total TX retry count can be specified for each packet, while the number of TX attempts before scaling rate can be configured only globally (not per each packet). Currently the driver sets the HW auto rate fallback mechanism to quickly scale rate after a couple of retries, and it uses the alternate rate requested by mac80211 as fallback limit rate (and it does this even wrongly). The HW indeed will behave differently than what mac80211 mandates, that is probably undesirable, and the reported TX retry count may not refer to what mac80211 thinks, and this could fool mac80211. This patch makes the driver to declare to mac80211 to support only one rate configuration for each packet, and it does disable the HW auto rate fallback mechanism, relying only on SW and letting mac80211 to do all by itself. This should ensure correct operation and fairness respect to mac80211. Indeed here tests with iperf do not show significant performance differences. Signed-off-by:
Andrea Merello <andrea.merello@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Andrea Merello authored
HW is programmed with wrong retry count value for TX: Mac80211 passes to driver the number of times the TX should be attempted. The HW, instead, wants the number of time the TX should be retried if it fails the first time (assuming we have to TX it at least one time). This patch correct this. Signed-off-by:
-
Andrea Merello authored
Rtl8187se support has been added to the rtl818x_pci driver by extracting a lot of information from a rtl8187se Linux staging driver included in the kernel at the time rtl8187se support was added. The rtl818x_pci main file has a comment that advertises this. Recently this staging driver has been removed from the kernel, but I still feel it can be useful as "reference" code (in case of bugs, or to implement improvements in rtl818x_pci driver). This one-line patch adds a comment in rtl818x_pci driver to point people searching for that "reference code" to the last kernel version still containing it (3.14). Signed-off-by:
-
Andrea Merello authored
Measuring time between _end_ of CTS-to-self and _end_ of datapacket (with a prism54 board and mac80211 hacked to let the MAC timestamp stay untouched in the radiotap header) resulted in about 300uS, while the datapacket itself should be by far shorter (less than 100uS) and IFS should be SIFS (10uS). This measure was confirmed whith a scope: about 250uS IFS has been seen between the two packets. This situation causes the CTS-to-self protection mechanism to work incorrectly due to the NAV expiring during, or even before beginning, the packet transmission, and it also causes the performances to be anyway reduced due to time waste. This problem has been seen at every packet TXed with CTS-to-self enabled on rtl8185 board. rtl8187se seems not affected (and rtl8180, being a 802.11b card, does not have CTS-to-self mechaninsm). This patch fixes this by adding a magic register write, making the board wait for correct SIFS after CTS-to-self packet. Signed-off-by:
-
Andrea Merello authored
BSSID register was written with six byte-writes. It seems that, similarly to what happens with MAC registers, they needs to be written with one 16-bit and one 32-bit writes, otherwise the write does not work. The byte write didn't work only on my rtl8185, while it worked on rtl8180 and rtl8187se, BTW since there are probably a number of different ASIC revisions out of there, I let the change to affect all cards. It shouldn't hurt anyway. Signed-off-by:
-
Rafał Miłecki authored
LCNXN is simply a continuation of N, e.g. code handling LCNXN revs 0 and 1 is mostly the same as for N-PHY revs 7+. Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
-
Fabian Frederick authored
Fix checkpatch warning: WARNING: kfree(NULL) is safe this check is probably not required Cc: Stanislav Yakovlev <stas.yakovlev@gmail.com> Cc: "John W. Linville" <linville@tuxdriver.com> Cc: linux-wireless@vger.kernel.org Signed-off-by:
Fabian Frederick <fabf@skynet.be> Signed-off-by:
-
Alexey Khoroshilov authored
The patch fixes a couple of issues: - absence of deallocation of rsi_dev->rx_usb_urb[0] in the driver; - potential NULL pointer dereference because of lack of checks for memory allocation success in rsi_init_usb_interface(). By the way, it makes rsi_probe() returning error code instead of 1 and fixes comments regarding returning values. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
-
Alexey Khoroshilov authored
Signed-off-by:
-
Rajkumar Manoharan authored
Right now sleep duration is configured as beacon interval. It should be the multiple of beacon interval by listen period which helps to reduce station power consumption. Signed-off-by:
Rajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by:
-
Rajkumar Manoharan authored
Earlier the listen interval is used to decide switching between operating and off-channels during bgscan and to improve throughput, the listen interval is reduced to 1. After optimiztion in scan state machine, listen period is not used for decision making and hence reverting it back to original value. Signed-off-by:
-
Rajkumar Manoharan authored
The beacon configurations are not cached properly after the station associates with AP. Not handling BEACON_INFO, is failing to update dtim period and also it is causing below warning message. WARNING: CPU: 1 PID: 0 at drivers/net/wireless/ath/ath9k/recv.c:548 ath_rx_tasklet+0xc89/0xca0 [ath9k]() Call Trace: [<c14669c9>] dump_stack+0x48/0x69 [<c104f1a2>] warn_slowpath_common+0x82/0xa0 [<fd38c2f9>] ? ath_rx_tasklet+0xc89/0xca0 [ath9k] [<fd38c2f9>] ? ath_rx_tasklet+0xc89/0xca0 [ath9k] Signed-off-by:
-
Mathy Vanhoef authored
Treat frames that underwent a CCK or OFDM restart as frames with an invalid CRC. Signed-off-by:
Mathy Vanhoef <vanhoefm@gmail.com> Signed-off-by:
-
Mathy Vanhoef authored
When the FIF_FCSFAIL filter flag is set, pass frames with CRC errors. Signed-off-by:
-
- Jun 26, 2014
-
-
Thomas Gleixner authored
Why is converting time formats so desired if there are proper interfaces for this? Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Bing Zhao <bzhao@marvell.com> Cc: "John W. Linville" <linville@tuxdriver.com> Cc: linux-wireless@vger.kernel.org Signed-off-by:
-
Bing Zhao authored
This reverts commit a82fc3b4a2bceb7c6587249cb690342eb5065979. Thomas corrected me on that I misunderstood Johannes' comment for net_timedelta() and the ktime_get_real() usage inside __net_timestamp(). Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Fengguang Wu authored
CC: "Rafał Miłecki" <zajec5@gmail.com> CC: "John W. Linville" <linville@tuxdriver.com> Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
Jahnavi Meher authored
Fixed a warning related to incorrect return type and removed an unnecessary semi colon. Signed-off-by:
Jahnavi Meher <jahnavi.meher@gmail.com> Signed-off-by:
-
Jahnavi Meher authored
Fixed a potential buffer overflow in 'rsi_rates' and a sparse warning related to difference in endianness in rsi_91x_mgmt.c. Signed-off-by:
-
Luis R. Rodriguez authored
The p54 driver uses request_firmware() twice, once for actual firmware and then another time for an optional user overide on EEPROM, 3826.eeprom. The custom EEPROM is optional but if not present we'll introduce an extra lag of 60 seconds with udev present. Annotate we don't want udev nonsense here to avoid the lag in case its not present. This was found with the following SmPL patch. @ firmware_not_critical @ expression cf; expression config_file; expression dev; int ret; identifier l; statement S; @@ - ret = request_firmware(&cf, config_file, dev); + ret = request_firmware_direct(&cf, config_file, dev); if (ret < 0) { ... when != goto l; when != return ret; when any } else { ... release_firmware(cf); ... } Cc: Takashi Iwai <tiwai@suse.de> Cc: Christian Lamparter <chunkeey@googlemail.com> Cc: linux-wireless@vger.kernel.org Cc: cocci@systeme.lip6.fr Signed-off-by:Luis R. Rodriguez <mcgrof@suse.com> Acked-By:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Rajkumar Manoharan authored
Signed-off-by:
-
Rajkumar Manoharan authored
Fix tx gain table index on fast channel change for AR953x. Signed-off-by:
-
Rajkumar Manoharan authored
Signed-off-by:
-
Rajkumar Manoharan authored
Signed-off-by:
-
Rajkumar Manoharan authored
Signed-off-by:
-
Rafał Miłecki authored
Clean ucode selection, fix choice of firmware for LCN, drop some goto-s, add new devices. Tested on 14e4:4312, 14e4:4315, 14e4:4328, 14e4:432b, 14e4:4353. Signed-off-by:
-
Rickard Strandqvist authored
For consistency with other drivers, replace a magic number by a macro. Signed-off-by:
Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Reviewed-by:
Peter Wu <peter@lekensteyn.nl> Signed-off-by:
-
Rickard Strandqvist authored
For consistency with other drivers, replace a magic number by a macro. Signed-off-by:
-
Rickard Strandqvist authored
bt_msr & 0xfc will never match 0x3. Fix this by using a mask that actually matches the available types. Signed-off-by:
-
Rickard Strandqvist authored
bt_msr & 0xfc will never match 0x3. Fix this by using a mask that actually matches the available types. Signed-off-by:
-
Rickard Strandqvist authored
bt_msr & 0xfc will never match 0x3. Fix this by using a mask that actually matches the available types. Signed-off-by:
-
Rafał Miłecki authored
Add support for external PA and clean code a bit. Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Arend van Spriel authored
The users of the fwil put an error message in the log so there is no need to do the same in the lower level functions in fwil when the firmware on the device returns an error. Some errors can be ignored for the driver to function and this will avoid driver users to point at the low-level error message as potential bug. 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:
-
Daniel Kim authored
Instead of controlling mpc setting during scan operation, initialize mpc setting and then let firmware take care of it. Reviewed-by:
Daniel Kim <dekim@broadcom.com> [arend@broadcom.com: keep mpc setting for bcm4329] Signed-off-by:
-
Arend van Spriel authored
All log messages were set to TRACE level, which is intended for function entry and exit. Using INFO instead in other places. Also reducing an error message that always popped up upon module unload. Reviewed-by:
-
Franky Lin authored
Passing a pointer from user space and using it directly in driver is not a preferable behavior. Switch to cfg80211 vendor mode for dongle command for better cross platform compatibility. Reviewed-by:
Franky Lin <frankyl@broadcom.com> Signed-off-by:
-
Hante Meuleman authored
Some of the USB devices also have Bluetooth inside. These devices can with specific firmware result in a composite USB device. This change will update the driver such that it will also accept the correct interface of composite devices. It is backward compatible with old non-composite USB fw. Reviewed-by:
-
Arend van Spriel authored
After updating 2G bandwidth capability clear ht info. This will be properly set upon calling brcmf_update_wiphy_bands(). Reviewed-by:
-
Hante Meuleman authored
Add the USB 43566 device to the supported devices list. The 43566 is a WiFi-only variant of the 43569. It uses the same FW as 43569. Reviewed-by:
-
