- 07 Oct, 2014 5 commits
-
-
Marek Puzyniak authored
hw pointer of ath_hw is not assigned to proper value in function ath9k_hw_reset what finally causes kernel panic. This can be solved by proper initialization of ath_hw in ath9k_init_priv. Signed-off-by:
Marek Puzyniak <marek.puzyniak@tieto.com> Acked-by:
Oleksij Rempel <linux@rempel-privat.de> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Sujith Manoharan authored
When a channel context is removed, the hw_queue_base is set to -1, this will result in a panic because ath9k_chanctx_stop_queues() can be called on an interface that is not assigned to any context yet - for example, when trying to scan. Fix this issue by setting the hw_queue_base to zero when a channel context is removed. Signed-off-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by:
-
Sujith Manoharan authored
drivers/net/wireless/ath/main.c:88 ath_printk() error: we previously assumed 'common->hw' could be null (see line 82) Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Andrea Merello authored
Currently the allowed "respose rate" set (rates for HW generated frames like ACKs) is the same as the basic rate set. The HW will use the higher allowed response rate that is lower than the rate of the received frame. This is more or less what IEEE80211 mandates, but I missed the fact that IEEE80211 also says that whenever it happens that for a modulation class there is no any rate in the basic rates set, then the response rate set shall include also all the mandatory rates for that modulation class. This patch adds mandatory OFDM rates to the allowed response rate set if no OFDM rate is included in the basic rate set. Depending by the AP, I faced cases in which this patch seems to cause a noticeable perfomance improvement. - With my usual test AP there is no particular perfomance difference. - With a prism54/hostapd AP this patch causes RX thoughput increase from about 5Mbps to about 20Mbps. Hopefully this patch may help people that faced performance regression wrt the old staging driver. Signed-off-by:
Andrea Merello <andrea.merello@gmail.com> Signed-off-by:
-
-
- 02 Oct, 2014 22 commits
-
-
Larry Finger authored
Indenting errors yielded the following static checker warnings: drivers/net/wireless/rtlwifi/rtl8192ee/hw.c:533 rtl92ee_set_hw_reg() warn: add curly braces? (if) drivers/net/wireless/rtlwifi/rtl8192ee/hw.c:539 rtl92ee_set_hw_reg() warn: add curly braces? (if) An unreleased version of the static checker also reported: drivers/net/wireless/rtlwifi/rtl8723be/trx.c:550 rtl8723be_rx_query_desc() warn: 'hdr' can't be NULL. drivers/net/wireless/rtlwifi/rtl8188ee/trx.c:621 rtl88ee_rx_query_desc() warn: 'hdr' can't be NULL. drivers/net/wireless/rtlwifi/rtl8192ee/trx.c:567 rtl92ee_rx_query_desc() warn: 'hdr' can't be NULL. drivers/net/wireless/rtlwifi/rtl8821ae/trx.c:758 rtl8821ae_rx_query_desc() warn: 'hdr' can't be NULL. drivers/net/wireless/rtlwifi/rtl8723ae/trx.c:494 rtl8723e_rx_query_desc() warn: 'hdr' can't be NULL. drivers/net/wireless/rtlwifi/rtl8192se/trx.c:315 rtl92se_rx_query_desc() warn: 'hdr' can't be NULL. drivers/net/wireless/rtlwifi/rtl8192ce/trx.c:392 rtl92ce_rx_query_desc() warn: 'hdr' can't be NULL. All of these are fixed. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Reported-by:
-
Larry Finger authored
The driver needs btcoexist, but Kconfig fails to select it. This omission could cause build errors for some configurations. Signed-off-by:
-
Sujith Manoharan authored
When we are attempting to switch to a new channel context, the TX queues are flushed, but the mac80211 queues are not stopped and traffic can still come down to the driver. This patch fixes it by stopping the queues assigned to the current context/vif before trying to flush. Signed-off-by:
-
Sujith Manoharan authored
When a full chip reset is done, all the queues across all VIFs are stopped, but if MCC is enabled, only the queues of the current context is awakened, when we complete the reset. This results in unfairness for the inactive context. Since frames are queued internally in the driver if there is a context mismatch, we can awaken all the queues when coming out of a reset. The VIF-specific queues are still used in flow control, to ensure fairness when traffic is high. Signed-off-by:
-
Sujith Manoharan authored
This can be used when the queues of a context needs to be stopped. Signed-off-by:
-
Sujith Manoharan authored
Change the ath9k_chanctx_wake_queues() API so that we can pass the channel context that needs its queues to be stopped. Signed-off-by:
-
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 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 13 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:
-
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:
-
