- 02 Oct, 2014 16 commits
-
-
Sujith Manoharan authored
When draining of the TX queues fails, a full HW reset is done. ath_reset() makes sure that the queues in mac80211 are restarted, so there is no need to wake them up again. Signed-off-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Sujith Manoharan authored
ath9k_has_tx_pending() can be used to check if there are pending frames instead of having duplicate code. Signed-off-by:
-
Sujith Manoharan authored
Checking for the queue depth outside of the TX queue lock is incorrect and in this case, is not required since it is done inside ath9k_has_pending_frames(). Signed-off-by:
-
Sujith Manoharan authored
There is no need to check if the current channel context has active ACs queued up if the TX queue is not empty. Signed-off-by:
-
Sujith Manoharan authored
Signed-off-by:
-
Avinash Patil authored
This patch adds SD8887 support to mwifiex. SD8887 is Marvell's 1x1 11ac solution. The corresponding firmware image file is located at: "mrvl/sd8887_uapsta.bin" Signed-off-by:
Avinash Patil <patila@marvell.com> Signed-off-by:
Cathy Luo <cluo@marvell.com> Signed-off-by:
Frank Huang <frankh@marvell.com> Signed-off-by:
Nishant Sarmukadam <nishants@marvell.com> Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
-
Avinash Patil authored
This patch adds some more defitions to card specific register structure and removes static defines for these registers. Signed-off-by:
-
Vladimir Kondratiev authored
Introduce netdev IOCTLs, to be used by the debug tools. Allows to read/write single dword value or memory block, aligned to dword Different address modes supported: - BAR offset - Firmware "linker" address - target's AHB bus Signed-off-by:
Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by:
-
Vladimir Kondratiev authored
Introduce manual FW recovery mode. It is activated if module parameter @no_fw_recovery set to true. May be changed at runtime. Recovery information provided by new "recovery" debugfs file. It prints: mode = [auto|manual] state = [idle|pending|running] In manual mode, after FW error, recovery won't start automatically. Instead, after notification to user space, recovery waits in "pending" state, as indicated by the "recovery" debugfs file. User space tools may perform data collection and allow to continue recovery by writing "run" to the "recovery" debugfs file. Alternatively, recovery pending may be canceled by stopping network interface i.e. 'ifconfig wlan0 down' Signed-off-by:
-
Sujith Manoharan authored
Signed-off-by:
-
John W. Linville authored
Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
-
Jukka Rissanen authored
We did not return error if multicast packet transmit failed. This might not be desired so return error also in this case. If there are multiple 6lowpan devices where the multicast packet is sent, then return error even if sending to only one of them fails. Signed-off-by:
Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com>
-
Jukka Rissanen authored
Make sure that we are able to return EAGAIN from l2cap_chan_send() even for multicast packets. The error code was ignored unncessarily. Signed-off-by:
-
Jukka Rissanen authored
If skb_unshare() returns NULL, then we leak the original skb. Solution is to use temp variable to hold the new skb. Signed-off-by:
-
Jukka Rissanen authored
The earlier multicast commit 36b3dd25 ("Bluetooth: 6lowpan: Ensure header compression does not corrupt IPv6 header") lost one skb free which then caused memory leak. Signed-off-by:
-
Johan Hedberg authored
The L2CAP connection's channel list lock (conn->chan_lock) must never be taken while already holding a channel lock (chan->lock) in order to avoid lock-inversion and lockdep warnings. So far the l2cap_chan_connect function has acquired the chan->lock early in the function and then later called l2cap_chan_add(conn, chan) which will try to take the conn->chan_lock. This violates the correct order of taking the locks and may lead to the following type of lockdep warnings: -> #1 (&conn->chan_lock){+.+...}: [<c109324d>] lock_acquire+0x9d/0x140 [<c188459c>] mutex_lock_nested+0x6c/0x420 [<d0aab48e>] l2cap_chan_add+0x1e/0x40 [bluetooth] [<d0aac618>] l2cap_chan_connect+0x348/0x8f0 [bluetooth] [<d0cc9a91>] lowpan_control_write+0x221/0x2d0 [bluetooth_6lowpan] -> #0 (&chan->lock){+.+.+.}: [<c10928d8>] __lock_acquire+0x1a18/0x1d20 [<c109324d>] lock_acquire+0x9d/0x140 [<c188459c>] mutex_lock_nested+0x6c/0x420 [<d0ab05fd>] l2cap_connect_cfm+0x1dd/0x3f0 [bluetooth] [<d0a909c4>] hci_le_meta_evt+0x11a4/0x1260 [bluetooth] [<d0a910eb>] hci_event_packet+0x3ab/0x3120 [bluetooth] [<d0a7cb08>] hci_rx_work+0x208/0x4a0 [bluetooth] CPU0 CPU1 ---- ---- lock(&conn->chan_lock); lock(&chan->lock); lock(&conn->chan_lock); lock(&chan->lock); Before calling l2cap_chan_add() the channel is not part of the conn->chan_l list, and can therefore only be accessed by the L2CAP user (such as l2cap_sock.c). We can therefore assume that it is the responsibility of the user to handle mutual exclusion until this point (which we can see is already true in l2cap_sock.c by it in many places touching chan members without holding chan->lock). Since the hci_conn and by exctension l2cap_conn creation in the l2cap_chan_connect() function depend on chan details we cannot simply add a mutex_lock(&conn->chan_lock) in the beginning of the function (since the conn object doesn't yet exist there). What we can do however is move the chan->lock taking later into the function where we already have the conn object and can that way take conn->chan_lock first. This patch implements the above strategy and does some other necessary changes such as using __l2cap_chan_add() which assumes conn->chan_lock is held, as well as adding a second needed label so the unlocking happens as it should. Reported-by:Marcel Holtmann <marcel@holtmann.org>
-
- 30 Sep, 2014 24 commits
-
-
Larry Finger authored
Configuration randconfig-1412075201 gets an error because driver rtl8821ae depends on driver btcoexist, but Kconfig does not select it. Reported-by:
Jim Davis <jim.epost@gmail.com> Cc: Jim Davis <jim.epost@gmail.com> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Maithili Hinge authored
When mwifiex device becomes GO, unicast traffic between client1 and GO stops when client2 connects to GO. Reason behind this was PTK getting overwritten by key_material command for client2 as it did not have client mac address. So, client1 can no more decode GO's ping packets though it responds to its broadcast packets. This patch adds case to check for BSS_ROLE instead of bss_type to set client mac address while configuring keys when device becomes GO. Signed-off-by:
Maithili Hinge <maithili@marvell.com> Signed-off-by:
-
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:
-
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:
-
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 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:
-
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:
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 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:
-
