[PATCH v4] cfg80211: Provision to allow the support for different beacon intervals

This commit provides the option for the host drivers to advertise the support for different beacon intervals among the respective interface combinations, through supp_diff_beacon_int (bool). Signed-off-by: Purushottam Kushwaha --- include/net/cfg80211.h | 4

[PATCH 2/2] ath9k: improve powersave filter handling

For non-aggregated frames, ath9k was leaving handling of powersave filtered packets to mac80211. This can be too slow if the intermediate queue is already filled with packets and mac80211 does not immediately send a new packet via drv_tx(). Improve response time with filtered frames by triggering

[PATCH 1/2] ath9k: use ieee80211_tx_status_noskb where possible

It removes the need for undoing the padding changes to skb->data and it improves performance by eliminating one tx status lookup per MPDU in the status path. It is also useful for preparing a follow-up fix to better handle powersave filtering. Signed-off-by: Felix Fietkau ---

Re: [v5.1] ucc_fast: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.

On Thursday, August 4, 2016 10:22:43 PM CEST Arvind Yadav wrote: > index df8ea79..ada9070 100644 > --- a/include/soc/fsl/qe/ucc_fast.h > +++ b/include/soc/fsl/qe/ucc_fast.h > @@ -165,10 +165,12 @@ struct ucc_fast_private { > int stopped_tx; /* Whether channel has been stopped for

Re: Wireless Workshop accepted into the 2016 Linux Kernel Summit and Linux Plumbers Conference

> Please join us for a timely and important discussion [4]! > > KS [5] will be held October 31-November 1 and LPC [6] will be held > November 1-4, both in Santa Fe, New Mexico, US. The workshop is going to be on November 1st, the combined day. I've put up a new wiki page here:

[PATCH] ath10k: hide kernel addresses from logs using %pK format specifier

From: Maharaja Kennadyrajan With the %pK format specifier we hide the kernel addresses with the help of kptr_restrict sysctl. In this patch, %p is changed to %pK in the driver code. The sysctl is documented in Documentation/sysctl/kernel.txt. Signed-off-by: Maharaja

[PATCH 0/2] get_expected_throughput interface update

These two patches are two important patches (mainly 1/2) that solve a regression issue that was found in wlcore (where wl was found to be null in some cases) Also, they make it easier for driver to get hw->priv when op is invoked. Maxim Altshul (2): mac80211/wlcore: Add ieee80211_hw variable

Re: [PATCH] ath10k: disable wake_tx_queue for older devices

On Thu, Aug 4, 2016 at 12:07 PM, Roman Yeryomin wrote: > On 1 August 2016 at 12:04, Dave Taht wrote: >> On Mon, Aug 1, 2016 at 1:35 AM, Roman Yeryomin wrote: >>> On 7 July 2016 at 19:30, Valo, Kalle

Re: [PATCH] ath10k: disable wake_tx_queue for older devices

On 1 August 2016 at 12:04, Dave Taht wrote: > On Mon, Aug 1, 2016 at 1:35 AM, Roman Yeryomin wrote: >> On 7 July 2016 at 19:30, Valo, Kalle wrote: >>> Michal Kazior writes: >>> Ideally

[PATCH] ath9k: fix AR5416 access GPIO warning

From: Miaoqing Pan The warning was seen on AR5416 chip, which invoke ath9k_hw_gio_get() before the GPIO initialized correctly. WARNING: CPU: 1 PID: 1159 at ~/drivers/net/wireless/ath/ath9k/hw.c:2776 ath9k_hw_gpio_get+0x148/0x1a0 [ath9k_hw] ... CPU: 1 PID:

Re: Buggy rhashtable walking

On Thu, Aug 04, 2016 at 03:18:46PM +0800, Herbert Xu wrote: > > So the question is can wireless handle seeing an entry multiple > times? In particular, __ieee80211_rx_handle_packet would appear > to process the same packet multiple times if this were to happen. It's worse than I thought. In

Buggy rhashtable walking

Hi: While working on rhashtable I noticed that wireless is walking rhashtables by hand using rht_for_each_*. You must not do that as an rhashtable can entail multiple hash tables when resizing. If you walk it by hand then you may end up missing entries. The correct way to do it is to use the

Re: [PATCH v2] nl80211: Receive correct value for NL80211_MESHCONF_HT_OPMODE command

> And I think checking only in wpa_supplicant is not good idea. Because > other user application can access to the kernel API. If invalid flag > combination causes kernel panic, it could be kernel vulnerability. > I don't really see how that should confuse a driver into a panic, but fair

Re: [PATCH] ath9k: fix GPIO mask for AR9462 and AR9565

Hi On 2016-08-04, Pan, Miaoqing wrote: > Sorry, try the patch. AR5416 will invoke ath9k_hw_gpio_get() before gpio > initialized correctly. > > Thanks, > Miaoqing Thanks a lot, the patch appears to work. Feel free to add Tested-by: Stefan Lippers-Hollmann and please