- 30 Sep, 2014 29 commits
-
-
Felix Fietkau authored
On AR9003, tx control and tx status are in separate descriptor rings. Tx duration is extracted from the tx control descriptor data, which ar9003_hw_proc_txdesc cannot access. Fix getting the duration by adding a separate callback for it. Acked-by:
Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Sujith Manoharan authored
chan_lock is not required for checking if we are in the middle of a HW reset, so do it early. This also removes the small window where the lock is dropped and reacquired. Signed-off-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by:
-
Hante Meuleman authored
Add basic wowl (magic packet and disconnect) support. This patch adds this support only for PCIE bus devices. This feature requires FW which has support for wowl built in. 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:
-
Hante Meuleman authored
When driver gets unloaded due to error situation there is a chance a packet gets received while fws has already been cleaned up. This will result in kernel crash. This patch adds a check to avoid this crash. Reviewed-by:
-
Arend van Spriel authored
In order to provision the P2P_DEVICE mac address using p2p_da_override iovar the discovery interface must be disabled. On some targets setting the mac address failed so disable the discovery interface to be certain. Reviewed-by:
-
Hante Meuleman authored
Msgbuf is using GFP_ATOMIC where GFP_KERNEL is also sufficient. On some platforms the coherent DMA memory is very limited when using GFP_ATOMIC. This patch changes usage of GFP_ATOMIC to GFP_KERNEL and uses worker to make this possible for creation of flowring. Reviewed-by:
-
Hante Meuleman authored
Need a cast to assure correct value is propagated. Reviewed-by:
-
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:
-
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:
-
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 11 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:
-
