- 30 Sep, 2014 22 commits
-
-
Hante Meuleman authored
Increase driver scan timeout from 8 to 10 seconds and report results to cfg80211. Without this patch the already received results were dropped on driver timeout. Reviewed-by:
Arend Van Spriel <arend@broadcom.com> Reviewed-by:
Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by:
Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by:
Daniel (Deognyoun) Kim <dekim@broadcom.com> Signed-off-by:
Hante Meuleman <meuleman@broadcom.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
On AR934x and newer SoC devices, the layout of the AR_RTC_PLL_CONTROL register changed. This currently breaks at least 5/10 MHz operation. AR933x uses the old layout. It might also have been causing other stability issues because of the different location of the PLL_BYPASS bit which needs to be set during PLL clock initialization. This patch also removes more instances of hardcoded register values in favor of properly computed ones with the PLL_BYPASS bit added. Reported-by:
Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Felix Fietkau authored
The cycpwr_thr1 value needs to be lower on the extension channel than on the control channel, similar to how the register settings are programmed in the initvals. Also drop the unnecessary check for HT40 - this register can always be written. This patch has been reported to improve HT40 stability and throughput in some environments. Signed-off-by:
-
Felix Fietkau authored
This reverts commit 09efc563 I've received reports that this change is decreasing throughput in some rare conditions on an AR9280 based device Cc: stable@vger.kernel.org Signed-off-by:
-
Avinash Patil authored
SKB lists have their own lock. So this lock is not needed. Signed-off-by:
Avinash Patil <patila@marvell.com> Signed-off-by:
-
Avinash Patil authored
This patch fixes an issue with rx processing function where we were decrementing rx_pending count twice. Patch also queues correct main_work item when rx_pending count reaches low watermark. Signed-off-by:
Cathy Luo <cluo@marvell.com> Signed-off-by:
-
Avinash Patil authored
A soft lockup was observed on ARM multicore platform while UDP RX iperf was running on station. Reason for this is delay_main_task was not taken into consideration while jumping to process_start. Now if delay_main_task is true, we would exit mwifiex_main_process instead of going to process_start again. This ensure other process is scheduled on this CPU and soft lockup is avoided. Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Kevin Gan <ganhy@marvell.com> Signed-off-by:
Marc Yang <yangyang@marvell.com> Signed-off-by:
-
Stanislaw Gruszka authored
After short chat with Ivo, we decided that I'll take maintenance of rt2x00 driver. Thanks for Ivo's great work in the past! Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Acked-by:
Ivo Van Doorn <ivdoorn@gmail.com> Signed-off-by:
-
Felix Fietkau authored
On AR934x rev 3, settin the ad-hoc flag completely messes up hardware state - beacons get stuck, almost no packets make it out, hardware is constantly reset. When leaving out that flag and setting up the hw like in AP mode, TSF timers won't be automatically synced, but at least the rest works. AR934x rev 2 and older are not affected by this bug Signed-off-by:
-
Felix Fietkau authored
It is needed for AR934x as well Signed-off-by:
-
Felix Fietkau authored
Needed for calling vmalloc()/vfree() Signed-off-by:
-
Larry Finger authored
In a number of places, kmalloc or valloc were used to acquire memory. To ensure that these locations are correctly initialized, the calls were changed to kzalloc and vzalloc. The change fixes a problem that was causing HT operations to be cancelled. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Larry Finger authored
rtlwifi: rtl8188ee: rtl8192com: rtl8192cu: rtl8192ee: rtl8723ae: rtl87323be: rtl8821ae: Use common cmd_send_packet A locking problem was found in routine _rtl92ee_cmd_send_packet() that led to system freezes. Upon inspection, several drivers had the same problem; however, the routines all used the same code. The common code has been moved into rtlwifi. Signed-off-by:
-
Larry Finger authored
Realtek released new drivers on 06/28/2014. These changes implement all their changes into the kernel version of the driver. In addition, these modifications are part of the process of unifying the Realtek and kernel code bases. Signed-off-by:
-
Larry Finger authored
This patch updates the driver to match the latest Realtek release, and it is an important step in getting the internal code source at Realtek to match the code in the kernel. The primary reason for this is to make it easier for Realtek to maintain the kernel source without requiring an intermediate like me. In this process of merging the two source repositories, there are a lot of changes in both, and this commit is rather large. Signed-off-by:
-
Larry Finger authored
Not only does this patch update the driver to match the latest Realtek release, it is an important step in getting the internal code source at Realtek to match the code in the kernel. The primary reason for this is to make it easier for Realtek to maintain the kernel source without requiring an intermediate like me. In this process of merging the two source repositories, there are a lot of changes in both, and this commit is rather large. Signed-off-by:
-
Larry Finger authored
This driver was entered into staging a few cycles ago because there was not time to integrate the Realtek version into the support routines in the kernel. Now that there is an effort to converg the code base from Linux and the Realtek repo, it is time to move this driver. In addition, all the updates included in the 06/28/2014 version of the Realtek drivers are included here. With this change, it will be necessary to delete the staging driver. That will be handled in a separate patch. As it impacts the staging tree, such a patch is sent to a different destination. Signed-off-by:
-
Larry Finger authored
The code fails to lock the skb queue, which leads to a number of problems. This patch also fixes a Sparse warning about using a memset of 1 byte. Signed-off-by:
-
Rafał Miłecki authored
This will allow us to define GPIO-attached devices (LEDs, buttons) in the the device tree. Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Hauke Mehrtens authored
This driver is used by the bcm53xx ARM SoC code. Now it is possible to give the address of the chipcommon core in device tree and bcma will search for all the other cores. Signed-off-by:
Hauke Mehrtens <hauke@hauke-m.de> Acked-by:
-
Amitkumar Karwar authored
We will now dump MAC, APU, CIU, ICU firmware memory segments also for PCIe interface. Following is the updated userspace script which reads firmware dump information. mwifiex_pcie_fw_dump.sh: #!/bin/bash ethtool --set-dump mlan0 0 ethtool --get-dump mlan0 ethtool --get-dump mlan0 data /tmp/ITCM.log ethtool --set-dump mlan0 1 ethtool --get-dump mlan0 ethtool --get-dump mlan0 data /tmp/DTCM.log ethtool --set-dump mlan0 2 ethtool --get-dump mlan0 ethtool --get-dump mlan0 data /tmp/SQRAM.log ethtool --set-dump mlan0 3 ethtool --get-dump mlan0 ethtool --get-dump mlan0 data /tmp/IRAM.log ethtool --set-dump mlan0 4 ethtool --get-dump mlan0 ethtool --get-dump mlan0 data /tmp/APU.log ethtool --set-dump mlan0 5 ethtool --get-dump mlan0 ethtool --get-dump mlan0 data /tmp/CIU.log ethtool --set-dump mlan0 6 ethtool --get-dump mlan0 ethtool --get-dump mlan0 data /tmp/ICU.log ethtool --set-dump mlan0 7 ethtool --get-dump mlan0 ethtool --get-dump mlan0 data /tmp/MAC.log Signed-off-by: -
Amitkumar Karwar authored
This patch takes care of missing error paths in firmware dump. Signed-off-by:
-
- 26 Sep, 2014 18 commits
-
-
Larry Finger authored
Signed-off-by:
-
Larry Finger authored
This driver was entered into staging a few cycles ago because there was not time to integrate the Realtek version into the support routines in the kernel. Now that there is an effort to converg the code base from Linux and the Realtek repo, it is time to move this driver. In addition, all the updates included in the 06/28/2014 version of the Realtek drivers are included here. With this change, it will be necessary to delete the staging driver. That will be handled in a separate patch. As it impacts the staging tree, such a patch is sent to a different destination. Signed-off-by:
-
Larry Finger authored
Not only does this patch update the driver to match the latest Realtek release, it is an important step in getting the internal code source at Realtek to match the code in the kernel. The primary reason for this is to make it easier for Realtek to maintain the kernel source without requiring an intermediate like me. In this process of merging the two source repositories, there are a lot of changes in both, and this commit is rather large. Signed-off-by:
-
Larry Finger authored
Addition of the new drivers and the update to a new version for the others lead to changes in all the core routines. Signed-off-by:
-
Larry Finger authored
Realtek released a new version of the drivers on 06/28/2014. This patch implements the new power-save code. These changes also force corresponding changes in the drivers. Signed-off-by:
-
Larry Finger authored
Signed-off-by:
-
Larry Finger authored
Signed-off-by:
-
Larry Finger authored
Each of the routines in the rtlwifi common driver needs to be modified for the coming changes. This patch prepares core.c, but also touches other files. Signed-off-by:
-
Larry Finger authored
Future patches will move the drivers for RTL8192EE and RTL8821AE from staging to the regular wireless tree. Here, the necessary features are added to the PCI driver. Other files are touched due to changes in the various data structs. Signed-off-by:
-
Larry Finger authored
When the rtlwifi family of drivers was converted to use a workqueue when entering or leaving power save mode (commits a269913c, a5ffbe0a, 41affd52, b9116b9a, and 6539306b), the code began scheduling work from the callback routine of a different workqueue with a resulting increase in overhead. Signed-off-by:
-
Larry Finger authored
The capability for 802.11ac will soon be added to these drivers. Once that is done, a bitmask will be too large for the data storage. Signed-off-by:
-
Sujith Manoharan authored
Clearing IEEE80211_TX_CTL_PS_RESPONSE in a frame that is not in the current context doesn't seem right. Instead make sure that we don't add such frames to the UAPSD queue by using a local variable. Signed-off-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by:
-
Sujith Manoharan authored
There is no reason why frames marked with IEEE80211_TX_CTL_TX_OFFCHAN have to be sent using the UAPSD queue. Since mac80211 makes sure that RoC is done before pushing an offchannel frame to the driver, we can use the normal TX queues for transmission. Signed-off-by:
-
Sujith Manoharan authored
Since we use IEEE80211_HW_QUEUE_CONTROL now, the CAB/Offchannel queues are registered as the last two queues. There is no need to check and reassign the queues in the TX start()/done() routines. CAB frames will not reach the tx() callback since we set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING and pull the buffered frames during beacon transmission. We also don't have a special HW queue for handling off-channel frames. Signed-off-by:
-
Stanislaw Gruszka authored
Two bits control TX power on BBP_R1 register. Correct the mask, otherwise we clear additional bit on BBP_R1 register, what can have unknown, possible negative effect. Cc: stable@vger.kernel.org Signed-off-by:
-
Vladimir Kondratiev authored
Provide ethtool support; with support for interrupt coalescing through get_coalesce/set_coalesce. Placeholders for begin/complete will be used by runtime PM to make sure target is powered up while performing ethtool operations Signed-off-by:
Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by:
-
Rafał Miłecki authored
GPIOs can be also used on bcm53xx, however this arch requires different implementation of IRQ support. It uses different IRQ number (117) and different masks & acking. Signed-off-by:
-
andrea.merello authored
This patch makes the driver to report signal strength information to mac80211 for rtl8187se boards. It differs from my previous RFT patch: http://marc.info/?l=linux-wireless&m=140155388332534&w=2 because: - I have now a working rtl8187se card, so I could serve my RFT by myself. :) - CCK measurement code has changed a bit, but it does basically the same things. - OFDM measurement method is changed because the older method reported incorrect measures, at least for signals stronger than -40dBm). CCK measurement seems quite good. OFDM seems less accurate, but this is the same as the "reference" staging driver dose. I wanted not to change things just to make measures of _one_ (my) card a bit more close to what _I_ (in my setup) expected.. IMHO results are still good enough to justify reporting signal in dBm rather than in "unspecified" units, so this is what this patch actually does. Results of my tests with a working rtl8187se card connected with coaxes and various RF attenuators to my AP are: Input (approx) | CCK meas | OFDM meas -------------------------------------- -30dBm | -32dBm | -31dBm -40dBm | -40dBm | -41dBm -50dBm | -50dBm | -55dBm -60dBm | -59dBm | -63dBm -70dBm | -69dBm | -73dBm -80dBm | -79dBm | -83dBm Also some real-field tests has been done (no coax, packets in the air) for the CCK measure method, and they resulted in reasonable values. Thanks-to: Bernhard Schiffner <bernhard@schiffner-limbach.de> [ for real-field tests] Signed-off-by:
andrea.merello <andrea.merello@gmail.com> Signed-off-by:
-
