Re: pull-request: iwlwifi firmwares update 2017-02-03

[Luca Coelho]

Hi Kyle,

On Fri, 2017-02-03 at 10:41 +0200, Luca Coelho wrote:
> Hi Kyle,
> 
> We have updated some of our old firmware releases and also added a new
> release, version 27, for the newer devices.  More details in the tag
> description.
> 
> Please pull or let me know if there are any issues.

Are there any issues with this?

I forgot to say that I'm going to be sending the iwlwifi firmwares out
now (as I have been maintaining the iwlwifi driver upstream).  Emmanuel
can confirm that. :)

--
Cheers,
Luca.

signature.asc
Description: This is a digitally signed message part

Re: [Patch] NFC: trf7970a:

[Mark Greer]

On Sun, Dec 18, 2016 at 08:07:33PM -0700, Mark Greer wrote:
> On Sat, Dec 17, 2016 at 04:19:04PM -0500, Geoff Lansberry wrote:
> > Mark,   from our consultant:
> > 
> > It isn't important whether the flood script is successful in writing
> > or not. The point of it is to force a segfault by making many
> > requests. It needs to run for several hundred iterations (successful
> > or not) in order to generate the segfault.
> 
> So neard crashes even when the write fails??  Okay, I'll let it run for
> a while tomorrow (Monday).

[Okay, so not exactly "tomorrow" but I did get back to this.]

Geoff, a few things:

1) Any update on these issues?

2) Do you have all of the NFC-related patches from the nfc-next master
branch?  In particular, do you have all of Thierry's patches to
net/nfc/digial_*.c dated around June-July 2016?  Without those patches,
I see a panic; with them, I don't.

3) Assuming you have all of those patches, please revert the one with the
summary line of, "NFC: digital: Set the command pending flag", and tell me
if that stops the "Bogus state" messages.  I don't know which repo/branch
you're using so I can't provide a commit id.

Thanks,

Mark
--

Re: [Patch] NFC: trf7970a:

[Mark Greer]

I just realized that the linux-nfc is not CC'd so adding it.

On Wed, Feb 08, 2017 at 03:53:39PM -0700, Mark Greer wrote:
> On Sun, Dec 18, 2016 at 08:07:33PM -0700, Mark Greer wrote:
> > On Sat, Dec 17, 2016 at 04:19:04PM -0500, Geoff Lansberry wrote:
> > > Mark,   from our consultant:
> > > 
> > > It isn't important whether the flood script is successful in writing
> > > or not. The point of it is to force a segfault by making many
> > > requests. It needs to run for several hundred iterations (successful
> > > or not) in order to generate the segfault.
> > 
> > So neard crashes even when the write fails??  Okay, I'll let it run for
> > a while tomorrow (Monday).
> 
> [Okay, so not exactly "tomorrow" but I did get back to this.]
> 
> Geoff, a few things:
> 
> 1) Any update on these issues?
> 
> 2) Do you have all of the NFC-related patches from the nfc-next master
> branch?  In particular, do you have all of Thierry's patches to
> net/nfc/digial_*.c dated around June-July 2016?  Without those patches,
> I see a panic; with them, I don't.
> 
> 3) Assuming you have all of those patches, please revert the one with the
> summary line of, "NFC: digital: Set the command pending flag", and tell me
> if that stops the "Bogus state" messages.  I don't know which repo/branch
> you're using so I can't provide a commit id.
> 
> Thanks,
> 
> Mark
> --

Re: Installing driver for Ubuntu 16.04 Intel(R) Wireless WiFi Link 4965AGN

[Leopoldo]

Dear Sedat,

Absolutely clear. As you are my primary contact there, you can extent my 
question to the people there.


I much appreciate your assistance.

Kind regards,

Leopoldo


El 06/02/17 a las 07:01, Sedat Dilek escribió:

On Sun, Feb 5, 2017 at 6:31 PM, Leopoldo  wrote:

Dear Sedat,

Did you have the chance to have a look to this?


No.
If it was not clear said: I did not promise to look at it, I just said
sent the logs and people here can look at it.

- Sedat -


Kind regards.

Leopoldo


El 16/01/17 a las 21:33, Leopoldo escribió:

Dear Sedat,

Please, find attached the requested 2 files.

Thanking you invaluable collaboration.

Leopoldo


El 02/01/17 a las 20:39, Sedat Dilek escribió:

On Mon, Jan 2, 2017 at 7:11 PM,   wrote:

Dear Madam Sedat,

Hehe, my family name is indeed a female first name - Sedat is male.

Thank you for your answer.

I already consulted Ubuntu Community but it is not so nice for a beginner
like me. I tried several recomedations from them, but no way.  So, I
thought, it is better to ask to the source.

Yes, I have the firmware you mention, but wifi doesn't work. The icon appear
in the top bar but it doesn't seem to be conected. It doesn't seach
conections even when wifi is activated. The ligh of wifi simbol in the
laptop lights some times but others it doesn't.

It's difficult to answer without knowing anything about your hardware,
your WLAN infrastructure and your WLAN setup on Ubuntu/xenial.

It might be helpful if you attach your linux-config and dmesg output.

$ cp -v /boot/config-$(uname -r) /tmp
$ dmesg > /tmp/dmesg.txt

Attach those two files from /tmp directory and people can look at this.

- Sedat -

Any help is welcome and I won't forget ladies next time, sorry.

Thank you for your help and have a happy new year 2017 also.

Regards,
Leopoldo




El 02-01-2017 15:06, Sedat Dilek escribió:

On Mon, Jan 2, 2017 at 2:11 PM,   wrote:

Dear Sirs,
Which of the below drivers should I install for my Lenovo 3000 V200?
I am runing Ubuntu 16.04

Intel® Wireless WiFi Link 4965AGN
2.6.24+ iwlwifi-4965-ucode-4.44.14.tgz
2.6.24+ iwlwifi-4965-ucode-4.44.15.tgz
2.6.24+ iwlwifi-4965-ucode-4.44.17.tgz
2.6.24+ iwlwifi-4965-ucode-4.44.1.18.tgz
2.6.24+ iwlwifi-4965-ucode-4.44.1.20.tgz
2.6.24+ iwlwifi-4965-ucode-228.57.1.21.tgz
2.6.28+ (?) iwlwifi-4965-ucode-228.57.2.21.tgz
2.6.28+ (?) iwlwifi-4965-ucode-228.57.2.23.tgz
2.6.28+ (?) iwlwifi-4965-ucode-228.61.2.24.tgz

Ans how shoudl I proceed for intalling the right driver?

Thank you

[ What about the Ladies, Sir :-)? ]

Happy new 2017!

You need the linux-firmware [1] package.
Normally, Ubuntu/xenial should ship it.

Check if you have...

/lib/firmware/iwlwifi-4965-2.ucode

...file.

Not sure why you are asking or what is not working.
AFAICS, Ubuntu should have some nice wikis explaining a WLAN setup.
A good strategy will always be to consult your distro's help before asking
here.

[3] as a gift.

Regards,
- Sedat -

[1] http://packages.ubuntu.com/xenial/linux-firmware
[2] http://packages.ubuntu.com/xenial/all/linux-firmware/filelist
[3] http://www.catb.org/~esr/faqs/smart-questions.html

Re: pull-request: iwlwifi-next 2017-02-08

[Kalle Valo]

Luca Coelho  writes:

> Here's my third and final pull-request intended for v4.11.  As I
> mentioned before, I concentrated on our bugfix patches this time.  More
> details in the tag description.
>
> I have sent this out before, but I didn't get kbuildbot results yet. 
> Hopefully there will be no issues.  I'm sending it out already because
> you asked me to send this before 9pm today (I'm probably 1 or 2 minutes
> late :P).  It's up to you whether you want to pull it as is or wait for
> kbuildbot results.
>
> Please let me know if there are any issues.
>
> Cheers,
> Luca.
>
>
> The following changes since commit 8364fbb497f00de21d6d347194fa8b6bbae1d6f5:
>
>   iwlwifi: mvm: support new beacon template command (2017-02-06 19:19:27 
> +0200)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git 
> tags/iwlwifi-next-for-kalle-2017-02-08
>
> for you to fetch changes up to 0c8d0a4770cb6863f78a25c8d211f42e9c82251c:
>
>   iwlwifi: mvm: avoid exceeding the allowed print length (2017-02-08 17:54:23 
> +0200)
>
> 
> Some patches focusing on bugfixes for v4.11:
>
>   * Fix 802.11w, which was failing to due an IGTK bug;
>   * A few more bugzilla bug fixes;
>   * A channel-switch race condition fix;
>   * Some fixes related to suspend/resume with new HW;
>   * The RF-kill saga continues;
>   * And some other fixes here and there...
>
> 

Pulled, thanks.

-- 
Kalle Valo

Re: [PATCH V2] mtd: bcm47xxsflash: use platform_(set|get)_drvdata

[Brian Norris]

On Mon, Jan 16, 2017 at 05:28:18PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> We have generic place & helpers for storing platform driver data so
> there is no reason for using custom priv pointer.
> 
> This allows cleaning up struct bcma_sflash from unneeded fields.
> 
> Signed-off-by: Rafał Miłecki 
> ---
> Kalle: This is mtd focused patch, so I guess it should go through mtd tree. Do
>you find bcma change important enough to care to Ack it? :)

Applied to l2-mtd.git.

pull-request: iwlwifi-next 2017-02-08

[Luca Coelho]

Hi Kalle,

Here's my third and final pull-request intended for v4.11.  As I
mentioned before, I concentrated on our bugfix patches this time.  More
details in the tag description.

I have sent this out before, but I didn't get kbuildbot results yet. 
Hopefully there will be no issues.  I'm sending it out already because
you asked me to send this before 9pm today (I'm probably 1 or 2 minutes
late :P).  It's up to you whether you want to pull it as is or wait for
kbuildbot results.

Please let me know if there are any issues.

Cheers,
Luca.


The following changes since commit 8364fbb497f00de21d6d347194fa8b6bbae1d6f5:

  iwlwifi: mvm: support new beacon template command (2017-02-06 19:19:27 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git 
tags/iwlwifi-next-for-kalle-2017-02-08

for you to fetch changes up to 0c8d0a4770cb6863f78a25c8d211f42e9c82251c:

  iwlwifi: mvm: avoid exceeding the allowed print length (2017-02-08 17:54:23 
+0200)


Some patches focusing on bugfixes for v4.11:

  * Fix 802.11w, which was failing to due an IGTK bug;
  * A few more bugzilla bug fixes;
  * A channel-switch race condition fix;
  * Some fixes related to suspend/resume with new HW;
  * The RF-kill saga continues;
  * And some other fixes here and there...


Avraham Stern (1):
  iwlwifi: mvm: Fix CSA received immediately after association

Emmanuel Grumbach (5):
  iwlwifi: mvm: use the PROBE_RESP_QUEUE to send deauth to unknown station
  iwlwifi: pcie: don't increment / decrement a bool
  iwlwifi: make RTPM depend on EXPERT
  iwlwifi: dvm: don't call << operator with a negative value
  iwlwifi: mvm: don't call << operator with a negative value

Golan Ben Ami (2):
  iwlwifi: pcie: Re-configure IVAR table after stop device
  iwlwifi: pcie: set STATUS_RFKILL immediately after interrupt

Golan Ben-Ami (1):
  iwlwifi: mvm: avoid exceeding the allowed print length

Goodstein, Mordechay (1):
  iwlwifi: mvm: avoid race condition in ADD_STA.

Gregory Greenman (1):
  iwlwifi: mvm: fix a print of NSS for HT rate

Haim Dreyfuss (3):
  iwlwifi: pcie: move msix conf functions above other functions
  iwlwifi: pcie: separate between SW and HW MSIX configuration
  iwlwifi: pcie: re-configure IVAR table after suspend-resume

Ilan Peer (1):
  iwlwifi: mvm: Fix removal of IGTK

Sara Sharon (2):
  iwlwifi: mvm: fix references to first_agg_queue in DQA mode
  iwlwifi: mvm: fix reorder timer re-arming

 drivers/net/wireless/intel/iwlwifi/Kconfig |   7 ++-
 drivers/net/wireless/intel/iwlwifi/dvm/rs.c|   5 +-
 drivers/net/wireless/intel/iwlwifi/mvm/fw.c|  20 +++
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c  |  15 +++--
 drivers/net/wireless/intel/iwlwifi/mvm/rs.c|   6 +-
 drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c  |   3 +-
 drivers/net/wireless/intel/iwlwifi/mvm/sta.c   |   7 ++-
 drivers/net/wireless/intel/iwlwifi/mvm/tx.c|  17 +++---
 drivers/net/wireless/intel/iwlwifi/pcie/internal.h |   2 +-
 drivers/net/wireless/intel/iwlwifi/pcie/rx.c   |   8 ++-
 drivers/net/wireless/intel/iwlwifi/pcie/trans.c| 243 
++--
 11 files changed, 188 insertions(+), 145 deletions(-)

signature.asc
Description: This is a digitally signed message part

[PATCH 17/17] iwlwifi: mvm: avoid exceeding the allowed print length

[Luca Coelho]

From: Golan Ben-Ami 

Divide a mfuart related print so it won't exceed the allowed
MAX_MSG_LEN (110 bytes) per print.

Fixes: 19f63c531b85 ("iwlwifi: mvm: support v2 of mfuart load notification")
Signed-off-by: Golan Ben-Ami 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
index c42ef8681b75..45cb4f476e76 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
@@ -1396,19 +1396,15 @@ void iwl_mvm_rx_mfuart_notif(struct iwl_mvm *mvm,
struct iwl_rx_packet *pkt = rxb_addr(rxb);
struct iwl_mfuart_load_notif *mfuart_notif = (void *)pkt->data;
 
+   IWL_DEBUG_INFO(mvm,
+  "MFUART: installed ver: 0x%08x, external ver: 0x%08x, 
status: 0x%08x, duration: 0x%08x\n",
+  le32_to_cpu(mfuart_notif->installed_ver),
+  le32_to_cpu(mfuart_notif->external_ver),
+  le32_to_cpu(mfuart_notif->status),
+  le32_to_cpu(mfuart_notif->duration));
+
if (iwl_rx_packet_payload_len(pkt) == sizeof(*mfuart_notif))
IWL_DEBUG_INFO(mvm,
-  "MFUART: installed ver: 0x%08x, external ver: 
0x%08x, status: 0x%08x, duration: 0x%08x, image size: 0x%08x\n",
-  le32_to_cpu(mfuart_notif->installed_ver),
-  le32_to_cpu(mfuart_notif->external_ver),
-  le32_to_cpu(mfuart_notif->status),
-  le32_to_cpu(mfuart_notif->duration),
+  "MFUART: image size: 0x%08x\n",
   le32_to_cpu(mfuart_notif->image_size));
-   else
-   IWL_DEBUG_INFO(mvm,
-  "MFUART: installed ver: 0x%08x, external ver: 
0x%08x, status: 0x%08x, duration: 0x%08x\n",
-  le32_to_cpu(mfuart_notif->installed_ver),
-  le32_to_cpu(mfuart_notif->external_ver),
-  le32_to_cpu(mfuart_notif->status),
-  le32_to_cpu(mfuart_notif->duration));
 }
-- 
2.11.0

Re: ath10k: remove unneeded semicolon

[Kalle Valo]

Waldemar Rymarkiewicz  wrote:
> Remove redundant semicolon after switch statement.
> 
> Signed-off-by: Waldemar Rymarkiewicz 

Patch applied to ath-next branch of ath.git, thanks.

dab55d1083db ath10k: remove unneeded semicolon

-- 
https://patchwork.kernel.org/patch/9552819/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH V3 4/9] brcmfmac: add struct brcmf_pub parameter to the __brcmf_err

[Rafał Miłecki]

On 2017-02-08 15:52, Kalle Valo wrote:

Rafał Miłecki  writes:


On 2017-02-08 10:54, Arend Van Spriel wrote:

On 2-2-2017 22:33, Rafał Miłecki wrote:

From: Rafał Miłecki 

This will allow getting struct device reference from the passed
brcmf_pub for the needs of dev_err. More detailed messages are 
really

important for home routers which frequently have 2 (or even 3)
wireless
cards supported by brcmfmac.

Note that all calls are yet to be updated as for now brcmf_err macro
always passes NULL. This will be handled in following patch to make
this
change easier to review.


I prefer brcmf_err() to have struct device reference directly
instead of
using brcmf_pub. That would remove the need for patches 5 till 7 as 
bus

specific code already has struct device. So I have acked the first
three
patches, but would like to revise 8 and 9.

Kalle,

I acked the first three patches. Can those three still go in for 
4.11?


Sounds OK to me. Kalle, I ack Arend's request if it isn't too late.


Ok, I'll try. My plan is to get everything ready for linux-next by
tomorrow morning (Finland time), let's see how it goes.

Related to this, Rafał are you still deleting the patches from 
patchwork

which should be dropped? I think you are as I can't see patches 4-9
anymore.

Now that my patchwork setup is much better (compared to how it was over
a year ago) I would actually prefer that you don't do that anymore. The
problem is that when you delete the patch from patchwork it completely
disappears from patchwork and I can't check the patch or discussion
anymore. And I'm so accustomed to use patchwork that only seldom I use
email to find the patch.

So it would be better to leave the patches as is and let me drop them
(=change the state Changes Requested, Rejected or similar), which is
trivial with my script. Otherwise I get this unsure feeling of what
happened to the patch :)


Yeah, that was me (marked 4-9 as Changes Requested), sorry ;) I won't be 
messing with patches in the future.

RE: KASAN+netlink, was: [PATCH] [net-next?] hns: avoid stack overflow with CONFIG_KASAN

[David Laight]

> From: Johannes Berg
> Sent: 08 February 2017 12:24
...
> Btw, what's causing this to start with? Can't the compiler reuse the
> stack places?

Only if it realises they've gone out of scope - which probably
doesn't happen when the functions are inlined.
The address of the parameter can be saved by the calling function
and used in a later call.

Something like this is valid:

int foo(int *p, int v)
{
static int *sv;
int old = -1;
if (sv) {old = *sv; *sv = v;}
sv = v;
return old;
}

void bar(...) {
int a, b;
...
foo(, 0);
...
foo(, 1);
...
foo(NULL, 2);
...

If the compiler starts sharing stack it all goes wrong.

David

Re: [PATCH net-next v2 00/12] net: dsa: remove unnecessary phy.h include

[Kalle Valo]

David Miller  writes:

> From: Florian Fainelli 
> Date: Tue,  7 Feb 2017 15:02:53 -0800
>
>> I'm hoping this doesn't conflict with what's already in net-next...
>> 
>> David, this should probably go via your tree considering the diffstat.
>
> I think you need one more respin.  Are you doing an allmodconfig build?
> If not, for something like this it's a must:
>
> drivers/net/wireless/ath/wil6210/cfg80211.c:24:30: error: expected ‘)’ before 
> ‘bool’
>  module_param(disable_ap_sme, bool, 0444);
>   ^
> drivers/net/wireless/ath/wil6210/cfg80211.c:25:34: error: expected ‘)’ before 
> string constant
>  MODULE_PARM_DESC(disable_ap_sme, " let user space handle AP mode SME");
>   ^
> Like like that file needs linux/module.h included.

Johannes already fixed a similar (or same) problem in my tree:

wil6210: include moduleparam.h

https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/?id=949c2d0096753d518ef6e0bd8418c8086747196b

I'm planning to send you a pull request tomorrow which contains that
one.

-- 
Kalle Valo

[PATCH 16/17] iwlwifi: mvm: Fix removal of IGTK

[Luca Coelho]

From: Ilan Peer 

When removing an IGTK, iwl_mvm_send_sta_igtk() was
called before station ID was retrieved, so the function
was invoked with an invalid station ID. Fix this by first
getting the station ID.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=192411
Signed-off-by: Ilan Peer 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
index 1bad933b3ad4..c35fabdf85da 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
@@ -3047,6 +3047,11 @@ int iwl_mvm_remove_sta_key(struct iwl_mvm *mvm,
 
/* Get the station from the mvm local station table */
mvm_sta = iwl_mvm_get_key_sta(mvm, vif, sta);
+   if (!mvm_sta) {
+   IWL_ERR(mvm, "Failed to find station\n");
+   return -EINVAL;
+   }
+   sta_id = mvm_sta->sta_id;
 
IWL_DEBUG_WEP(mvm, "mvm remove dynamic key: idx=%d sta=%d\n",
  keyconf->keyidx, sta_id);
@@ -3074,8 +3079,6 @@ int iwl_mvm_remove_sta_key(struct iwl_mvm *mvm,
return 0;
}
 
-   sta_id = mvm_sta->sta_id;
-
ret = __iwl_mvm_remove_sta_key(mvm, sta_id, keyconf, mcast);
if (ret)
return ret;
-- 
2.11.0

Re: [PATCH net-next v2 00/12] net: dsa: remove unnecessary phy.h include

[David Miller]

From: Florian Fainelli 
Date: Tue,  7 Feb 2017 15:02:53 -0800

> I'm hoping this doesn't conflict with what's already in net-next...
> 
> David, this should probably go via your tree considering the diffstat.

I think you need one more respin.  Are you doing an allmodconfig build?
If not, for something like this it's a must:

drivers/net/wireless/ath/wil6210/cfg80211.c:24:30: error: expected ‘)’ before 
‘bool’
 module_param(disable_ap_sme, bool, 0444);
  ^
drivers/net/wireless/ath/wil6210/cfg80211.c:25:34: error: expected ‘)’ before 
string constant
 MODULE_PARM_DESC(disable_ap_sme, " let user space handle AP mode SME");
  ^
Like like that file needs linux/module.h included.

Thanks.

[PATCH 11/17] iwlwifi: dvm: don't call << operator with a negative value

[Luca Coelho]

From: Emmanuel Grumbach 

In https://bugzilla.kernel.org/show_bug.cgi?id=177341 Bob
reported a UBSAN WARNING on rs.c.

Undefined behaviour in drivers/net/wireless/intel/iwlwifi/dvm/rs.c:746:18

This because
i = index - 1;
for (mask = (1 << i); i >= 0; i--, mask >>= 1)

is unsafe: i could be negative and hence we can call <<
on a negative value.
This bug doesn't have any real impact since the condition
of the for loop will prevent any usage of mask.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177341
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/dvm/rs.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/rs.c 
b/drivers/net/wireless/intel/iwlwifi/dvm/rs.c
index 710dbbefd551..ff44ebc5829d 100644
--- a/drivers/net/wireless/intel/iwlwifi/dvm/rs.c
+++ b/drivers/net/wireless/intel/iwlwifi/dvm/rs.c
@@ -740,7 +740,10 @@ static u16 rs_get_adjacent_rate(struct iwl_priv *priv, u8 
index, u16 rate_mask,
 
/* Find the previous rate that is in the rate mask */
i = index - 1;
-   for (mask = (1 << i); i >= 0; i--, mask >>= 1) {
+   if (i >= 0)
+   mask = BIT(i);
+
+   for (; i >= 0; i--, mask >>= 1) {
if (rate_mask & mask) {
low = i;
break;
-- 
2.11.0

[PATCH 15/17] iwlwifi: mvm: avoid race condition in ADD_STA.

[Luca Coelho]

From: "Goodstein, Mordechay" 

The race happens when we send ADD_STA(auth->assoc) -> LQ_CMD
between the commands the FW sometimes loses the medium for AUX, and
sends a ndp to the AP and the flow becomes, ADD_STA -> send ndp -> LQ_CMD
the problem is that there's no rates yet defined for sending the ndp and
FW generates an assert.

The fix: change the order of the commands to LQ_CMD -> ADD_STA

Signed-off-by: Mordechay Goodstein 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index 7253b92792bf..d37b1695c64e 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -2627,11 +2627,10 @@ static int iwl_mvm_mac_sta_state(struct ieee80211_hw 
*hw,
mvmvif->ap_assoc_sta_count++;
iwl_mvm_mac_ctxt_changed(mvm, vif, false, NULL);
}
+
+   iwl_mvm_rs_rate_init(mvm, sta, mvmvif->phy_ctxt->channel->band,
+true);
ret = iwl_mvm_update_sta(mvm, vif, sta);
-   if (ret == 0)
-   iwl_mvm_rs_rate_init(mvm, sta,
-mvmvif->phy_ctxt->channel->band,
-true);
} else if (old_state == IEEE80211_STA_ASSOC &&
   new_state == IEEE80211_STA_AUTHORIZED) {
 
-- 
2.11.0

[PATCH 14/17] iwlwifi: mvm: Fix CSA received immediately after association

[Luca Coelho]

From: Avraham Stern 

The session protection set for association is only removed when
BSS_CHANGED_BEACON_INFO is set and BSS_CHANGED_ASSOC is not set.

However, mac80211 may set both on association (in case a beacon was
already received). In this case, mac80211 will not set
BSS_CHANGED_BEACON_INFO on the next beacons because it has already
notified the beacon change, so the session protection is never removed
(until the session protection ends).

When a CSA is received within this time, the station will fail to
folllow the channel switch because it cannot schedule the time event.

Fix this by removing the session protection when
BSS_CHANGED_BEACON_INFO and BSS_CHANGED_ASSOC are both set.

Signed-off-by: Avraham Stern 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index 15ecd3aba71b..7253b92792bf 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -2008,16 +2008,16 @@ static void iwl_mvm_bss_info_changed_station(struct 
iwl_mvm *mvm,
if (fw_has_capa(>fw->ucode_capa,
IWL_UCODE_TLV_CAPA_UMAC_SCAN))
iwl_mvm_config_scan(mvm);
-   } else if (changes & BSS_CHANGED_BEACON_INFO) {
+   }
+
+   if (changes & BSS_CHANGED_BEACON_INFO) {
/*
-* We received a beacon _after_ association so
+* We received a beacon from the associated AP so
 * remove the session protection.
 */
iwl_mvm_remove_time_event(mvm, mvmvif,
  >time_event_data);
-   }
 
-   if (changes & BSS_CHANGED_BEACON_INFO) {
iwl_mvm_sf_update(mvm, vif, false);
WARN_ON(iwl_mvm_enable_beacon_filter(mvm, vif, 0));
}
-- 
2.11.0

[PATCH 13/17] iwlwifi: pcie: set STATUS_RFKILL immediately after interrupt

[Luca Coelho]

From: Golan Ben Ami 

Currently, when getting a RFKILL interrupt, the transport enters a flow
in which it stops the device, disables other interrupts, etc. After
stopping the device, the transport resets the hw, and sleeps. During
the sleep, a context switch occurs and host commands are sent by upper
layers (e.g. mvm) to the fw. This is possible since the op_mode layer
and the transport layer hold different mutexes.

Since the STATUS_RFKILL bit isn't set, the transport layer doesn't
recognize that RFKILL was toggled on, and no commands can actually be
sent, so it enqueues the command to the tx queue and sets a timer on
the queue.

After switching context back to stopping the device, STATUS_RFKILL is
set, and then the transport can't send the command to the fw.
This eventually results in a queue hang.

Fix this by setting STATUS_RFKILL immediately when
the interrupt is fired.

Signed-off-by: Golan Ben-Ami 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c 
b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
index e1bf6da20909..de94dfdf2ec9 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
@@ -1609,6 +1609,9 @@ irqreturn_t iwl_pcie_irq_handler(int irq, void *dev_id)
 
mutex_lock(_pcie->mutex);
hw_rfkill = iwl_is_rfkill_set(trans);
+   if (hw_rfkill)
+   set_bit(STATUS_RFKILL, >status);
+
IWL_WARN(trans, "RF_KILL bit toggled to %s.\n",
 hw_rfkill ? "disable radio" : "enable radio");
 
@@ -1617,7 +1620,6 @@ irqreturn_t iwl_pcie_irq_handler(int irq, void *dev_id)
iwl_trans_pcie_rf_kill(trans, hw_rfkill);
mutex_unlock(_pcie->mutex);
if (hw_rfkill) {
-   set_bit(STATUS_RFKILL, >status);
if (test_and_clear_bit(STATUS_SYNC_HCMD_ACTIVE,
   >status))
IWL_DEBUG_RF_KILL(trans,
@@ -1954,6 +1956,9 @@ irqreturn_t iwl_pcie_irq_msix_handler(int irq, void 
*dev_id)
 
mutex_lock(_pcie->mutex);
hw_rfkill = iwl_is_rfkill_set(trans);
+   if (hw_rfkill)
+   set_bit(STATUS_RFKILL, >status);
+
IWL_WARN(trans, "RF_KILL bit toggled to %s.\n",
 hw_rfkill ? "disable radio" : "enable radio");
 
@@ -1962,7 +1967,6 @@ irqreturn_t iwl_pcie_irq_msix_handler(int irq, void 
*dev_id)
iwl_trans_pcie_rf_kill(trans, hw_rfkill);
mutex_unlock(_pcie->mutex);
if (hw_rfkill) {
-   set_bit(STATUS_RFKILL, >status);
if (test_and_clear_bit(STATUS_SYNC_HCMD_ACTIVE,
   >status))
IWL_DEBUG_RF_KILL(trans,
-- 
2.11.0

[PATCH 12/17] iwlwifi: mvm: don't call << operator with a negative value

[Luca Coelho]

From: Emmanuel Grumbach 

In https://bugzilla.kernel.org/show_bug.cgi?id=177341 Bob
reported a UBSAN WARNING on rs.c in iwldvm.
Fix the same bug in iwlmvm.

This because
i = index - 1;
for (mask = (1 << i); i >= 0; i--, mask >>= 1)

is unsafe: i could be negative and hence we can call <<
on a negative value.
This bug doesn't have any real impact since the condition
of the for loop will prevent any usage of mask.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177341
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
index 13be9a5b83ee..ce907c58ebf6 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
@@ -972,7 +972,9 @@ static u16 rs_get_adjacent_rate(struct iwl_mvm *mvm, u8 
index, u16 rate_mask,
 
/* Find the previous rate that is in the rate mask */
i = index - 1;
-   for (mask = (1 << i); i >= 0; i--, mask >>= 1) {
+   if (i >= 0)
+   mask = BIT(i);
+   for (; i >= 0; i--, mask >>= 1) {
if (rate_mask & mask) {
low = i;
break;
-- 
2.11.0

[PATCH 09/17] iwlwifi: pcie: don't increment / decrement a bool

[Luca Coelho]

From: Emmanuel Grumbach 

David reported that the code I added uses the decrement
and increment operator on a boolean variable.

Fix that.

Fixes: 0cd58eaab148 ("iwlwifi: pcie: allow the op_mode to block the tx queues")
Reported-by: David Binderman 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h 
b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
index cf5bda06042c..10937309641a 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
@@ -279,7 +279,7 @@ struct iwl_txq {
bool frozen;
u8 active;
bool ampdu;
-   bool block;
+   int block;
unsigned long wd_timeout;
struct sk_buff_head overflow_q;
 
-- 
2.11.0

Re: [1/3] rt61pci: use entry directly

[Kalle Valo]

Stanislaw Gruszka  wrote:
> Signed-off-by: Stanislaw Gruszka 

3 patches applied to wireless-drivers-next.git, thanks.

80a97eae3046 rt61pci: use entry directly
2ceb813798e1 rt2x00: call entry directly in rt2x00_dump_frame
cf81db30a6ed rt2x00: remove queue_entry from skbdesc

-- 
https://patchwork.kernel.org/patch/9562469/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: rtlwifi: Move items out of rtl_pci_priv and rtl_usb_priv

[Kalle Valo]

Larry Finger  wrote:
> In commit 6773386f977c ("rtlwifi: rtl8192c-common: Fix "BUG: KASAN:"),
> a BUG detected when CONFIG_KASAN=y was fixed by reordering the layouts
> of struct rtl_pci_priv, and struct rtl_usb_priv so that the variables
> used by both PCI and USB drivers have the same offsets in both structs.
> The better fix of relocating the critical variables into struct rtl_priv
> was deferred as these changes do not have to be applied to stable
> kernels.
> 
> This change also removes CamelCase variables with pLed0 => pled0.
> 
> Signed-off-by: Larry Finger 

Patch applied to wireless-drivers-next.git, thanks.

d5efe1535af0 rtlwifi: Move items out of rtl_pci_priv and rtl_usb_priv

-- 
https://patchwork.kernel.org/patch/9560369/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [V3,1/9] brcmfmac: merge two brcmf_err macros into one

[Kalle Valo]

Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> This allows simplifying the code by adding a simple IS_ENABLED check for
> CONFIG_BRCMDB symbol.
> 
> Signed-off-by: Rafał Miłecki 
> Acked-by: Arend van Spriel 

3 patches applied to wireless-drivers-next.git, thanks.

9587a01a7ead brcmfmac: merge two brcmf_err macros into one
087fa712a006 brcmfmac: switch to C function (__brcmf_err) for printing errors
d0630555650a brcmfmac: merge two remaining brcmf_err macros

-- 
https://patchwork.kernel.org/patch/9553249/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: wil6210: include moduleparam.h

[Kalle Valo]

Johannes Berg  wrote:
> From: Johannes Berg 
> 
> This now declares a module parameter, so include the necessary
> header file for that.
> 
> Signed-off-by: Johannes Berg 

Patch applied to ath-next branch of ath.git, thanks.

949c2d009675 wil6210: include moduleparam.h

-- 
https://patchwork.kernel.org/patch/9560281/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: ath10k: select WANT_DEV_COREDUMP

[Kalle Valo]

Johannes Berg  wrote:
> From: Johannes Berg 
> 
> This is necessary so that - if ath10k is the only driver using
> dev_coredump*() - the functionality is built into the kernel.
> 
> Signed-off-by: Johannes Berg 

Patch applied to ath-next branch of ath.git, thanks.

5524ddd4c1f1 ath10k: select WANT_DEV_COREDUMP

-- 
https://patchwork.kernel.org/patch/9561349/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: KASAN+netlink, was: [PATCH] [net-next?] hns: avoid stack overflow with CONFIG_KASAN

[Andrey Ryabinin]

2017-02-08 16:10 GMT+03:00 Arnd Bergmann :
> On Wed, Feb 8, 2017 at 1:24 PM, Johannes Berg  
> wrote:

>
>> Btw, what's causing this to start with? Can't the compiler reuse the
>> stack places?
>
> I have no idea. It's trying to find out of bounds accesses for
> objects on the stack, so maybe it gives each variable a separate
> stack location in order to see which one caused problems?
>

If compiler cannot prove that access to the local variable is valid it
will add redzones around that variable
to be able to detect out of bounds accesses.

For example:
static inline int nla_put_u8(struct sk_buff *skb, int attrtype, u8 value)
{
   return nla_put(skb, attrtype, sizeof(u8), );
}
compiler will surround 'value' with redzones to catch potential oob
access in nla_put().


Another way to fix this, would be something like this:

#ifdef CONFIG_KASAN
/* don't bloat stack */
#define __noinline_for_kasan__noinline __maybe_unused
#else
#define __noinline_for_kasaninline
#endif

static __noinline_for_kasan int nla_put_u8(struct sk_buff *skb, int
attrtype, u8 value)
{
   return nla_put(skb, attrtype, sizeof(u8), );
}

[PATCH] mac80211: fix CSA in IBSS mode

[Koen Vandeputte]

Add the missing IBSS capability flag during capability init as it needs
to be inserted into the generated beacon in order for CSA to work.

Signed-off-by: Piotr Gawlowicz 
Signed-off-by: Mikołaj Chwalisz 
Tested-by: Koen Vandeputte 
---
 net/mac80211/ibss.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index a31d307..98999d3 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -487,14 +487,14 @@ int ieee80211_ibss_csa_beacon(struct 
ieee80211_sub_if_data *sdata,
struct beacon_data *presp, *old_presp;
struct cfg80211_bss *cbss;
const struct cfg80211_bss_ies *ies;
-   u16 capability = 0;
+   u16 capability = WLAN_CAPABILITY_IBSS;
u64 tsf;
int ret = 0;
 
sdata_assert_lock(sdata);
 
if (ifibss->privacy)
-   capability = WLAN_CAPABILITY_PRIVACY;
+   capability |= WLAN_CAPABILITY_PRIVACY;
 
cbss = cfg80211_get_bss(sdata->local->hw.wiphy, ifibss->chandef.chan,
ifibss->bssid, ifibss->ssid,
-- 
2.7.4

Re: [PATCH 00/17] iwlwifi: updates intended for v4.11 2017-02-08

[Coelho, Luciano]

On Wed, 2017-02-08 at 16:29 +0200, Kalle Valo wrote:
> Luca Coelho  writes:
> 
> > This is the third and final pull-request before 4.11's merge window.
> > This time I concentrated in bugfixes:
> > 
> > * Fix 802.11w, which was failing to due an IGTK bug;
> > * A few more bugzilla bug fixes;
> > * A channel-switch race condition fix;
> > * Some fixes related to suspend/resume with new HW;
> > * The RF-kill saga continues;
> > * And some other fixes here and there...
> > 
> > As usual, I'm pushing this to a pending branch, for kbuild bot, and
> > will send a pull-request later.
> > 
> > Please review.
> 
> I only see patches 1-8 in the mailing list or in my inbox, what happened
> to the rest?

Not sure, maybe they are still queued in my server? Let me check.

--
Luca.

Re: [PATCH 00/17] iwlwifi: updates intended for v4.11 2017-02-08

[Kalle Valo]

Luca Coelho  writes:

> This is the third and final pull-request before 4.11's merge window.
> This time I concentrated in bugfixes:
>
> * Fix 802.11w, which was failing to due an IGTK bug;
> * A few more bugzilla bug fixes;
> * A channel-switch race condition fix;
> * Some fixes related to suspend/resume with new HW;
> * The RF-kill saga continues;
> * And some other fixes here and there...
>
> As usual, I'm pushing this to a pending branch, for kbuild bot, and
> will send a pull-request later.
>
> Please review.

I only see patches 1-8 in the mailing list or in my inbox, what happened
to the rest?

-- 
Kalle Valo

[PATCH v4] wlcore: disable multicast filter in AP mode

[Iain Hunter]

Enable AP support for allmulticast for MDNS. It can be enabled by bringing
up the interface with ip command with argument allmulticast on

---

PATCH v4: fixes space in signed-off, tabbing for comment and indentation of 
closing bracket

 drivers/net/wireless/ti/wlcore/main.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/net/wireless/ti/wlcore/main.c 
b/drivers/net/wireless/ti/wlcore/main.c
index 3241e9eba73..242111cd016 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -3281,6 +3281,21 @@ static void wl1271_op_configure_filter(struct 
ieee80211_hw *hw,
if (ret < 0)
goto out_sleep;
}
+
+   /*
+* If interface in AP mode and created with allmulticast then 
disable
+* the firmware filters so that all multicast packets are passed
+* This is mandatory for MDNS based discovery protocols 
+*/
+   if (wlvif->bss_type == BSS_TYPE_AP_BSS) {
+   if (*total & FIF_ALLMULTI) {
+   ret = wl1271_acx_group_address_tbl(wl, wlvif,
+   false,
+   NULL, 0);
+   if (ret < 0)
+   goto out_sleep;
+   }
+   }
}
 
/*
-- 
2.11.0

ANNOUNCE: Netdev 2.1 seeking netdev conferences reporter(s)

[Jamal Hadi Salim]

Folks,

We are seeking for qualified people who love to write to cover the
netdev 2.1 conference.
The idea is to attend the different sessions and describe what
was discussed in a timely manner. We would like to publish the
events on a daily basis.

Requirements:
1) Passion about netdev
2) Knowledge of the different technical topics under discussion.
We will work to have you access knowledgeable people in the
different topics including the speaker.
3) Average writting skills. We will work to give you access to
people who have better writing skills than you.
4) Desire to be famous

cheers,
jamal

Re: [PATCH V3 4/9] brcmfmac: add struct brcmf_pub parameter to the __brcmf_err

[Rafał Miłecki]

On 2017-02-08 10:54, Arend Van Spriel wrote:

On 2-2-2017 22:33, Rafał Miłecki wrote:

From: Rafał Miłecki 

This will allow getting struct device reference from the passed
brcmf_pub for the needs of dev_err. More detailed messages are really
important for home routers which frequently have 2 (or even 3) 
wireless

cards supported by brcmfmac.

Note that all calls are yet to be updated as for now brcmf_err macro
always passes NULL. This will be handled in following patch to make 
this

change easier to review.


I prefer brcmf_err() to have struct device reference directly instead 
of

using brcmf_pub. That would remove the need for patches 5 till 7 as bus
specific code already has struct device. So I have acked the first 
three

patches, but would like to revise 8 and 9.

Kalle,

I acked the first three patches. Can those three still go in for 4.11?


Sounds OK to me. Kalle, I ack Arend's request if it isn't too late.

[PATCH 0/3] rt2x00 skb_desc cleanup

[Stanislaw Gruszka]

Remove entry field from skb_desc in order to use this skb_desc
place for other pointer.

This is intended to -next.

Stanislaw Gruszka (3):
  rt61pci: use entry directly
  rt2x00: call entry directly in rt2x00_dump_frame
  rt2x00: remove queue_entry from skbdesc

 drivers/net/wireless/ralink/rt2x00/rt2400pci.c   | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt2500pci.c   | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt2500usb.c   | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c   | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00.h  | 4 ++--
 drivers/net/wireless/ralink/rt2x00/rt2x00debug.c | 7 ---
 drivers/net/wireless/ralink/rt2x00/rt2x00dev.c   | 4 ++--
 drivers/net/wireless/ralink/rt2x00/rt2x00queue.c | 5 +
 drivers/net/wireless/ralink/rt2x00/rt2x00queue.h | 2 --
 drivers/net/wireless/ralink/rt2x00/rt61pci.c | 5 ++---
 drivers/net/wireless/ralink/rt2x00/rt73usb.c | 2 +-
 11 files changed, 16 insertions(+), 21 deletions(-)

-- 
1.8.3.1

[PATCH 1/3] rt61pci: use entry directly

[Stanislaw Gruszka]

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/ralink/rt2x00/rt61pci.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt61pci.c 
b/drivers/net/wireless/ralink/rt2x00/rt61pci.c
index 5306a3b..8adb5f3 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt61pci.c
@@ -1903,8 +1903,7 @@ static void rt61pci_write_tx_desc(struct queue_entry 
*entry,
 
rt2x00_desc_read(txd, 5, );
rt2x00_set_field32(, TXD_W5_PID_TYPE, entry->queue->qid);
-   rt2x00_set_field32(, TXD_W5_PID_SUBTYPE,
-  skbdesc->entry->entry_idx);
+   rt2x00_set_field32(, TXD_W5_PID_SUBTYPE, entry->entry_idx);
rt2x00_set_field32(, TXD_W5_TX_POWER,
   TXPOWER_TO_DEV(entry->queue->rt2x00dev->tx_power));
rt2x00_set_field32(, TXD_W5_WAITING_DMA_DONE_INT, 1);
-- 
1.8.3.1

Re: KASAN+netlink, was: [PATCH] [net-next?] hns: avoid stack overflow with CONFIG_KASAN

[Arnd Bergmann]

On Wed, Feb 8, 2017 at 1:24 PM, Johannes Berg  wrote:
> On Wed, 2017-02-08 at 13:03 +0100, Arnd Bergmann wrote:
>>
>> - Moving nla_put_{u8,u16,u32} out of line is probably uncontroversial
>> and
>>   it helps enough with br_netlink.c, but nl820211 is worse and needs
>> some
>>   additional fiddling.
>
> Why would that not be sufficient by itself for nl80211?

Oddly enough, it seems that it is now. I don't know what I was testing earlier,
but now I don't see any difference between this simple change, and the
modifications
I did on nl820211.c. I started out trying to fix this in nl820211.c
originally and then
later tried the extern nla_put_*(), but didn't think it helped all
that much then.

I'll just submit the simple patch then. ;-)

a) current mainline, arm64 allmodconfig+KASAN,
CONFIG_FRAME_WARN=1024

../net/wireless/nl80211.c: In function 'nl80211_get_mesh_config':
../net/wireless/nl80211.c:5689:1: warning: the frame size of 2336
bytes is larger than 1024 bytes
../net/wireless/nl80211.c: In function 'nl80211_send_iface':
../net/wireless/nl80211.c:2591:1: warning: the frame size of 1120
bytes is larger than 1024 bytes
../net/wireless/nl80211.c: In function 'nl80211_add_commands_unsplit.isra.2':
../net/wireless/nl80211.c:1410:1: warning: the frame size of 2272
bytes is larger than 1024 bytes
../net/wireless/nl80211.c: In function 'nl80211_set_wiphy':
../net/wireless/nl80211.c:2491:1: warning: the frame size of 1376
bytes is larger than 1024 bytes
../net/wireless/nl80211.c: In function 'nl80211_send_wiphy':
../net/wireless/nl80211.c:1895:1: warning: the frame size of 4288
bytes is larger than 1024 bytes
../net/wireless/nl80211.c: In function 'nl80211_send_station.isra.44':
../net/wireless/nl80211.c:4389:1: warning: the frame size of 2240
bytes is larger than 1024 bytes
../net/wireless/nl80211.c: In function 'nl80211_dump_station':
../net/wireless/nl80211.c:4441:1: warning: the frame size of 1456
bytes is larger than 1024 bytes
../net/wireless/nl80211.c: In function 'nl80211_get_station':
../net/wireless/nl80211.c:4478:1: warning: the frame size of 1232
bytes is larger than 1024 bytes
../net/wireless/nl80211.c: In function 'cfg80211_del_sta_sinfo':
../net/wireless/nl80211.c:13611:1: warning: the frame size of 1072
bytes is larger than 1024 bytes
../net/wireless/nl80211.c: In function 'nl80211_send_bss.isra.43.constprop':
../net/wireless/nl80211.c:7588:1: warning: the frame size of 1296
bytes is larger than 1024 bytes

b) with patch to move nla_put_* functions out of line:
../net/wireless/nl80211.c: In function 'nl80211_set_wiphy':
../net/wireless/nl80211.c:2491:1: warning: the frame size of 1376
bytes is larger than 1024 bytes
../net/wireless/nl80211.c: In function 'nl80211_dump_station':
../net/wireless/nl80211.c:4441:1: warning: the frame size of 1456
bytes is larger than 1024 bytes
../net/wireless/nl80211.c: In function 'nl80211_get_station':
../net/wireless/nl80211.c:4478:1: warning: the frame size of 1232
bytes is larger than 1024 bytes
../net/wireless/nl80211.c: In function 'cfg80211_del_sta_sinfo':
../net/wireless/nl80211.c:13611:1: warning: the frame size of 1072
bytes is larger than 1024 bytes
../net/wireless/nl80211.c: In function 'nl80211_dump_survey':
../net/wireless/nl80211.c:7753:1: warning: the frame size of 1136
bytes is larger than 1024 bytes

c) without --param asan-stack=1, checking just the functions above
against 100 bytes

../net/wireless/nl80211.c: In function 'nl80211_set_wiphy':
../net/wireless/nl80211.c:2491:1: warning: the frame size of 144 bytes
is larger than 100 bytes [-Wframe-larger-than=]
../net/wireless/nl80211.c: In function 'nl80211_send_wiphy':
../net/wireless/nl80211.c:1895:1: warning: the frame size of 224 bytes
is larger than 100 bytes [-Wframe-larger-than=]
../net/wireless/nl80211.c: In function 'nl80211_send_station.isra.44':
../net/wireless/nl80211.c:4389:1: warning: the frame size of 144 bytes
is larger than 100 bytes [-Wframe-larger-than=]
../net/wireless/nl80211.c: In function 'nl80211_dump_station':
../net/wireless/nl80211.c:4441:1: warning: the frame size of 912 bytes
is larger than 100 bytes [-Wframe-larger-than=]
../net/wireless/nl80211.c: In function 'nl80211_get_station':
../net/wireless/nl80211.c:4478:1: warning: the frame size of 864 bytes
is larger than 100 bytes [-Wframe-larger-than=]
../net/wireless/nl80211.c: In function 'cfg80211_del_sta_sinfo':
../net/wireless/nl80211.c:13611:1: warning: the frame size of 864
bytes is larger than 100 bytes [-Wframe-larger-than=]
../net/wireless/nl80211.c: In function 'nl80211_dump_survey':
../net/wireless/nl80211.c:7753:1: warning: the frame size of 112 bytes
is larger than 100 bytes [-Wframe-larger-than=]


> Btw, what's causing this to start with? Can't the compiler reuse the
> stack places?

I have no idea. It's trying to find out of bounds accesses for
objects on the stack, so maybe it gives each variable a separate
stack location in order to see which one caused problems?

 

[PATCH 2/3] rt2x00: call entry directly in rt2x00_dump_frame

[Stanislaw Gruszka]

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/ralink/rt2x00/rt2400pci.c   | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt2500pci.c   | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt2500usb.c   | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c   | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00.h  | 4 ++--
 drivers/net/wireless/ralink/rt2x00/rt2x00debug.c | 7 ---
 drivers/net/wireless/ralink/rt2x00/rt2x00dev.c   | 4 ++--
 drivers/net/wireless/ralink/rt2x00/rt2x00queue.c | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt61pci.c | 2 +-
 drivers/net/wireless/ralink/rt2x00/rt73usb.c | 2 +-
 10 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c 
b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
index 085c5b4..1987443 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
@@ -1200,7 +1200,7 @@ static void rt2400pci_write_beacon(struct queue_entry 
*entry,
/*
 * Dump beacon to userspace through debugfs.
 */
-   rt2x00debug_dump_frame(rt2x00dev, DUMP_FRAME_BEACON, entry->skb);
+   rt2x00debug_dump_frame(rt2x00dev, DUMP_FRAME_BEACON, entry);
 out:
/*
 * Enable beaconing again.
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2500pci.c 
b/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
index 9832fd5..791434d 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
@@ -1349,7 +1349,7 @@ static void rt2500pci_write_beacon(struct queue_entry 
*entry,
/*
 * Dump beacon to userspace through debugfs.
 */
-   rt2x00debug_dump_frame(rt2x00dev, DUMP_FRAME_BEACON, entry->skb);
+   rt2x00debug_dump_frame(rt2x00dev, DUMP_FRAME_BEACON, entry);
 out:
/*
 * Enable beaconing again.
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2500usb.c 
b/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
index cd3ab5a..6235746 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
@@ -1170,7 +1170,7 @@ static void rt2500usb_write_beacon(struct queue_entry 
*entry,
/*
 * Dump beacon to userspace through debugfs.
 */
-   rt2x00debug_dump_frame(rt2x00dev, DUMP_FRAME_BEACON, entry->skb);
+   rt2x00debug_dump_frame(rt2x00dev, DUMP_FRAME_BEACON, entry);
 
/*
 * USB devices cannot blindly pass the skb->len as the
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c 
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 572cdea..8223a15 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -1014,7 +1014,7 @@ void rt2800_write_beacon(struct queue_entry *entry, 
struct txentry_desc *txdesc)
/*
 * Dump beacon to userspace through debugfs.
 */
-   rt2x00debug_dump_frame(rt2x00dev, DUMP_FRAME_BEACON, entry->skb);
+   rt2x00debug_dump_frame(rt2x00dev, DUMP_FRAME_BEACON, entry);
 
/*
 * Write entire beacon with TXWI and padding to register.
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00.h 
b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
index ea299c4..26869b3 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
@@ -1400,11 +1400,11 @@ struct queue_entry *rt2x00queue_get_entry(struct 
data_queue *queue,
  */
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
 void rt2x00debug_dump_frame(struct rt2x00_dev *rt2x00dev,
-   enum rt2x00_dump_type type, struct sk_buff *skb);
+   enum rt2x00_dump_type type, struct queue_entry 
*entry);
 #else
 static inline void rt2x00debug_dump_frame(struct rt2x00_dev *rt2x00dev,
  enum rt2x00_dump_type type,
- struct sk_buff *skb)
+ struct queue_entry *entry)
 {
 }
 #endif /* CONFIG_RT2X00_LIB_DEBUGFS */
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c 
b/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
index 72ae530..964aefd 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
@@ -157,9 +157,10 @@ void rt2x00debug_update_crypto(struct rt2x00_dev 
*rt2x00dev,
 }
 
 void rt2x00debug_dump_frame(struct rt2x00_dev *rt2x00dev,
-   enum rt2x00_dump_type type, struct sk_buff *skb)
+   enum rt2x00_dump_type type, struct queue_entry 
*entry)
 {
struct rt2x00debug_intf *intf = rt2x00dev->debugfs_intf;
+   struct sk_buff *skb = entry->skb;
struct skb_frame_desc *skbdesc = get_skb_frame_desc(skb);
struct sk_buff *skbcopy;
struct rt2x00dump_hdr *dump_hdr;
@@ -196,8 +197,8 @@ void rt2x00debug_dump_frame(struct rt2x00_dev *rt2x00dev,

[PATCH 3/3] rt2x00: remove queue_entry from skbdesc

[Stanislaw Gruszka]

queue_entry field of skbdesc is not read any more, remove it to allow
skbdesc contain other data.

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/ralink/rt2x00/rt2x00queue.c | 3 ---
 drivers/net/wireless/ralink/rt2x00/rt2x00queue.h | 2 --
 2 files changed, 5 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c 
b/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
index 380daf4..e1660b9 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00queue.c
@@ -83,7 +83,6 @@ struct sk_buff *rt2x00queue_alloc_rxskb(struct queue_entry 
*entry, gfp_t gfp)
 */
skbdesc = get_skb_frame_desc(skb);
memset(skbdesc, 0, sizeof(*skbdesc));
-   skbdesc->entry = entry;
 
if (rt2x00_has_cap_flag(rt2x00dev, REQUIRE_DMA)) {
dma_addr_t skb_dma;
@@ -689,7 +688,6 @@ int rt2x00queue_write_tx_frame(struct data_queue *queue, 
struct sk_buff *skb,
goto out;
}
 
-   skbdesc->entry = entry;
entry->skb = skb;
 
/*
@@ -774,7 +772,6 @@ int rt2x00queue_update_beacon(struct rt2x00_dev *rt2x00dev,
 */
skbdesc = get_skb_frame_desc(intf->beacon->skb);
memset(skbdesc, 0, sizeof(*skbdesc));
-   skbdesc->entry = intf->beacon;
 
/*
 * Send beacon to hardware.
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00queue.h 
b/drivers/net/wireless/ralink/rt2x00/rt2x00queue.h
index 2233b91..22d1881 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00queue.h
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00queue.h
@@ -116,8 +116,6 @@ struct skb_frame_desc {
__le32 iv[2];
 
dma_addr_t skb_dma;
-
-   struct queue_entry *entry;
 };
 
 /**
-- 
1.8.3.1

[PATCH] cfg80211: fix NAN bands definition

[Luca Coelho]

From: Luca Coelho 

The nl80211_nan_dual_band_conf enumeration doesn't make much sense.
The default value is assigned to a bit, which makes it weird if the
default bit and other bits are set at the same time.

To improve this, get rid of NL80211_NAN_BAND_DEFAULT and add a wiphy
configuration to let the drivers define which bands are supported.
This is exposed to the userspace, which then can make a decision on
which band(s) to use.  Additionally, rename all "dual_band" elements
to "bands", to make things clearer.

Signed-off-by: Luca Coelho 
---
 include/net/cfg80211.h   | 18 ++
 include/uapi/linux/nl80211.h | 57 
 net/mac80211/cfg.c   |  4 ++--
 net/mac80211/trace.h | 16 ++---
 net/wireless/core.c  |  3 ++-
 net/wireless/nl80211.c   | 35 ---
 net/wireless/trace.h | 16 ++---
 7 files changed, 86 insertions(+), 63 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index a2c18b53e053..c92dc03c8528 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -5,7 +5,7 @@
  *
  * Copyright 2006-2010 Johannes Berg 
  * Copyright 2013-2014 Intel Mobile Communications GmbH
- * Copyright 2015-2016 Intel Deutschland GmbH
+ * Copyright 2015-2017 Intel Deutschland GmbH
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -2416,11 +2416,13 @@ struct cfg80211_qos_map {
  * This struct defines NAN configuration parameters
  *
  * @master_pref: master preference (1 - 255)
- * @dual: dual band operation mode, see  nl80211_nan_dual_band_conf
+ * @bands: operating bands, a bitmap of  nl80211_band values.
+ * For instance, for NL80211_BAND_2GHZ, bit 0 would be set
+ * (i.e. BIT(NL80211_BAND_2GHZ)).
  */
 struct cfg80211_nan_conf {
u8 master_pref;
-   u8 dual;
+   u8 bands;
 };
 
 /**
@@ -2428,11 +2430,11 @@ struct cfg80211_nan_conf {
  * configuration
  *
  * @CFG80211_NAN_CONF_CHANGED_PREF: master preference
- * @CFG80211_NAN_CONF_CHANGED_DUAL: dual band operation
+ * @CFG80211_NAN_CONF_CHANGED_BANDS: operating bands
  */
 enum cfg80211_nan_conf_changes {
CFG80211_NAN_CONF_CHANGED_PREF = BIT(0),
-   CFG80211_NAN_CONF_CHANGED_DUAL = BIT(1),
+   CFG80211_NAN_CONF_CHANGED_BANDS = BIT(1),
 };
 
 /**
@@ -3596,6 +3598,10 @@ struct wiphy_iftype_ext_capab {
  * attribute indices defined in  nl80211_bss_select_attr.
  *
  * @cookie_counter: unique generic cookie counter, used to identify objects.
+ * @nan_supported_bands: bands supported by the device in NAN mode, a
+ * bitmap of  nl80211_band values.  For instance, for
+ * NL80211_BAND_2GHZ, bit 0 would be set
+ * (i.e. BIT(NL80211_BAND_2GHZ)).
  */
 struct wiphy {
/* assign these fields before you register the wiphy */
@@ -3727,6 +3733,8 @@ struct wiphy {
 
u64 cookie_counter;
 
+   u8 nan_supported_bands;
+
char priv[0] __aligned(NETDEV_ALIGN);
 };
 
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index cd547b864595..5ed257c4cd4e 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -10,7 +10,7 @@
  * Copyright 2008, 2009 Luis R. Rodriguez 
  * Copyright 2008 Jouni Malinen 
  * Copyright 2008 Colin McCabe 
- * Copyright 2015  Intel Deutschland GmbH
+ * Copyright 2015-2017 Intel Deutschland GmbH
  *
  * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -854,12 +854,15 @@
  * cfg80211_scan_done().
  *
  * @NL80211_CMD_START_NAN: Start NAN operation, identified by its
- * %NL80211_ATTR_WDEV interface. This interface must have been previously
- * created with %NL80211_CMD_NEW_INTERFACE. After it has been started, the
- * NAN interface will create or join a cluster. This command must have a
- * valid %NL80211_ATTR_NAN_MASTER_PREF attribute and optional
- * %NL80211_ATTR_NAN_DUAL attributes.
- * After this command NAN functions can be added.
+ * %NL80211_ATTR_WDEV interface. This interface must have been
+ * previously created with %NL80211_CMD_NEW_INTERFACE. After it
+ * has been started, the NAN interface will create or join a
+ * cluster. This command must have a valid
+ * %NL80211_ATTR_NAN_MASTER_PREF attribute and optional
+ * %NL80211_ATTR_BANDS attributes.  If %NL80211_ATTR_BANDS is
+ * omitted or set to 0, it means don't-care and the device will
+ * decide what to use.  After this command NAN functions can be
+ * added.
  * @NL80211_CMD_STOP_NAN: Stop the NAN operation, identified by
  * its %NL80211_ATTR_WDEV interface.
  * @NL80211_CMD_ADD_NAN_FUNCTION: Add a NAN 

Re: [PATCH v4 3/5] cfg80211: Accept multiple RSSI thresholds for CQM

[Johannes Berg]

> > I think it would make sense to unconditionally apply the hysteresis
> > to low/high, i.e. always set
> >  low = low - hyst
> >  high = high + hyst
> > 
> > so that you get "sticky" ranges once you're in them?
> 
> Yes, maybe that's better, I guess I want to avoid just adding a lag /
> delay in reporting changes that are not due to measurement error or
> temporary.  Could also do something in between, e.g. use "low - hyst"
> if signal is close to low, otherwise just "low".

That's sort of what you had, but except for the precise definition of
"close", no?

Actually, no, because you used "last - hyst" rather than "low - hyst"
it's different. I think we can live with checking if it's close, say
setting to "low - hyst" when it's within low + hyst - that avoids the
problem I outlined above and gets a bit more responsiveness, I guess.

> The question is how the current hysteresis parameter is defined, what
> is expected of the firmware and how do driver authors decide whether
> their firmware/hardware implements the same mechanism as expected by
> the kernel.  Would the same thing happen with firmware
> implementations if the hysteresis value is 3 and the rssi fluctuates
> by +/- 2?  Or would it have to be +/- 3 or +/- 4 before this starts
> to happen.  (If this isn't well specified then it makes more sense to
> try to do it in one place for consistency.)

I'm not sure it's well-defined.

johannes

[PATCH v3] iw: Add support for controlling tx power for per station

[Ashok Raj Nagarajan]

This patch allows userspace to set transmit power, in mBm units, to a
station associated to the AP.

To set a limit tx power of 2000 mBm:
iw wlan0 station set  txpwr limit 2000

To revert the user defined tx power for a station:
iw wlan0 station set  txpwr auto

Signed-off-by: Ashok Raj Nagarajan 
---
v3:
- rebased

 station.c | 69 +++
 1 file changed, 69 insertions(+)

diff --git a/station.c b/station.c
index f3e3da8..8364593 100644
--- a/station.c
+++ b/station.c
@@ -569,6 +569,7 @@ COMMAND(station, del, " [subtype ] 
[reason-code ]",
 static const struct cmd *station_set_plink;
 static const struct cmd *station_set_vlan;
 static const struct cmd *station_set_mesh_power_mode;
+static const struct cmd *station_set_txpwr;
 
 static const struct cmd *select_station_cmd(int argc, char **argv)
 {
@@ -580,6 +581,8 @@ static const struct cmd *select_station_cmd(int argc, char 
**argv)
return station_set_vlan;
if (strcmp(argv[1], "mesh_power_mode") == 0)
return station_set_mesh_power_mode;
+   if (strcmp(argv[1], "txpwr") == 0)
+   return station_set_txpwr;
return NULL;
 }
 
@@ -731,6 +734,72 @@ COMMAND_ALIAS(station, set, " mesh_power_mode 
"
"Set link-specific mesh power mode for this station",
select_station_cmd, station_set_mesh_power_mode);
 
+static int handle_station_set_txpwr(struct nl80211_state *state,
+   struct nl_msg *msg,
+   int argc, char **argv,
+   enum id_input id)
+{
+   enum nl80211_tx_power_setting type;
+   unsigned char mac_addr[ETH_ALEN];
+   unsigned int sta_txpwr = 0;
+   char *err = NULL;
+
+   if (argc != 3 && argc != 4)
+   return 1;
+
+   if (mac_addr_a2n(mac_addr, argv[0])) {
+   fprintf(stderr, "invalid mac address\n");
+   return 2;
+   }
+
+   NLA_PUT(msg, NL80211_ATTR_MAC, ETH_ALEN, mac_addr);
+   argc--;
+   argv++;
+
+   if (strcmp("txpwr", argv[0]) != 0)
+   return 1;
+   argc--;
+   argv++;
+
+   if (!strcmp(argv[0], "auto"))
+   type = NL80211_TX_POWER_AUTOMATIC;
+   else if (!strcmp(argv[0], "limit"))
+   type = NL80211_TX_POWER_LIMITED;
+   else {
+   printf("Invalid parameter: %s\n", argv[0]);
+   return 2;
+   }
+
+   NLA_PUT_U32(msg, NL80211_ATTR_STA_TX_POWER_SETTING, type);
+
+   if (type != NL80211_TX_POWER_AUTOMATIC) {
+   if (argc != 2) {
+   printf("Missing TX power level argument.\n");
+   return 2;
+   }
+
+   argc--;
+   argv++;
+
+   sta_txpwr = strtoul(argv[0], , 0);
+   NLA_PUT_U32(msg, NL80211_ATTR_STA_TX_POWER, sta_txpwr);
+   }
+
+   argc--;
+   argv++;
+
+   if (argc)
+   return 1;
+
+   return 0;
+ nla_put_failure:
+   return -ENOBUFS;
+}
+COMMAND_ALIAS(station, set, " txpwr  []",
+   NL80211_CMD_SET_STATION, 0, CIB_NETDEV, handle_station_set_txpwr,
+   "Set Tx power for this station.",
+   select_station_cmd, station_set_txpwr);
+
 static int handle_station_dump(struct nl80211_state *state,
   struct nl_msg *msg,
   int argc, char **argv,
-- 
1.9.1

[PATCH v3] ath10k: add support for controlling tx power to a station

[Ashok Raj Nagarajan]

This patch will add the support to control the transmit power for traffic
to a station associated with the AP. Userspace provide the transmit power
value in mBm units. ath10k firmware expects the value to be in dBm and
hence will convert the value from to dBm before passing down to firmware.

Underlying FW will enforce that the maximum tx power will be based on the
regulatory requirements. If the user given transmit power is greater than
the allowed tx power in the given channel, then the FW will use the maximum
tx power in the same channel.

When 0 is sent to the FW as tx power, it will revert to the automatic tx
power for the station.

Signed-off-by: Ashok Raj Nagarajan 
---
v3:
- reword commit log
- remove range check for the input from user. (Ben Greear)

 drivers/net/wireless/ath/ath10k/mac.c | 31 +++
 drivers/net/wireless/ath/ath10k/wmi.h |  1 +
 2 files changed, 32 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 9977829..3b91468 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5985,6 +5985,32 @@ static int ath10k_mac_tdls_vifs_count(struct 
ieee80211_hw *hw)
return num_tdls_vifs;
 }
 
+static int ath10k_sta_set_txpwr(struct ieee80211_hw *hw,
+   struct ieee80211_vif *vif,
+   struct ieee80211_sta *sta)
+{
+   struct ath10k *ar = hw->priv;
+   struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
+   int ret = 0;
+   u16 txpwr;
+
+   txpwr = MBM_TO_DBM(sta->txpwr);
+
+   mutex_lock(>conf_mutex);
+
+   ret = ath10k_wmi_peer_set_param(ar, arvif->vdev_id, sta->addr,
+   WMI_PEER_USE_FIXED_PWR, txpwr);
+   if (ret) {
+   ath10k_warn(ar, "failed to set tx power for station ret: %d\n",
+   ret);
+   goto out;
+   }
+
+out:
+   mutex_unlock(>conf_mutex);
+   return ret;
+}
+
 static int ath10k_sta_state(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct ieee80211_sta *sta,
@@ -7550,6 +7576,7 @@ static void ath10k_mac_op_sta_pre_rcu_remove(struct 
ieee80211_hw *hw,
.set_key= ath10k_set_key,
.set_default_unicast_key= ath10k_set_default_unicast_key,
.sta_state  = ath10k_sta_state,
+   .sta_set_txpwr  = ath10k_sta_set_txpwr,
.conf_tx= ath10k_conf_tx,
.remain_on_channel  = ath10k_remain_on_channel,
.cancel_remain_on_channel   = ath10k_cancel_remain_on_channel,
@@ -8193,11 +8220,15 @@ int ath10k_mac_register(struct ath10k *ar)
ar->hw->wiphy->iface_combinations = ath10k_10x_if_comb;
ar->hw->wiphy->n_iface_combinations =
ARRAY_SIZE(ath10k_10x_if_comb);
+   wiphy_ext_feature_set(ar->hw->wiphy,
+ NL80211_EXT_FEATURE_STA_TX_PWR);
break;
case ATH10K_FW_WMI_OP_VERSION_10_4:
ar->hw->wiphy->iface_combinations = ath10k_10_4_if_comb;
ar->hw->wiphy->n_iface_combinations =
ARRAY_SIZE(ath10k_10_4_if_comb);
+   wiphy_ext_feature_set(ar->hw->wiphy,
+ NL80211_EXT_FEATURE_STA_TX_PWR);
break;
case ATH10K_FW_WMI_OP_VERSION_UNSET:
case ATH10K_FW_WMI_OP_VERSION_MAX:
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index 861c2d8..1ccb6bf 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -5811,6 +5811,7 @@ enum wmi_peer_param {
WMI_PEER_CHAN_WIDTH = 0x4,
WMI_PEER_NSS= 0x5,
WMI_PEER_USE_4ADDR  = 0x6,
+   WMI_PEER_USE_FIXED_PWR = 0x8,
WMI_PEER_DUMMY_VAR  = 0xff, /* dummy parameter for STA PS workaround */
 };
 
-- 
1.9.1

[PATCH v3 2/2] mac80211: store tx power value from user to station

[Ashok Raj Nagarajan]

This patch introduce a new driver callback drv_sta_set_txpwr. This API will
copy the transmit power value passed from user space and call the driver
callback to set the tx power for the station.

Signed-off-by: Ashok Raj Nagarajan 
---
v3:
- Store txpwr in mBm units. Push down the converstions at the driver
  level (Ben Greear)
 include/net/mac80211.h|  6 ++
 net/mac80211/cfg.c|  8 
 net/mac80211/driver-ops.c | 21 +
 net/mac80211/driver-ops.h |  5 +
 net/mac80211/trace.h  | 27 +++
 5 files changed, 67 insertions(+)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 5345d35..49d48f3 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1777,6 +1777,8 @@ struct ieee80211_sta_rates {
  * This is defined by the spec (IEEE 802.11-2012 section 8.3.2.2 NOTE 2).
  * @support_p2p_ps: indicates whether the STA supports P2P PS mechanism or not.
  * @max_rc_amsdu_len: Maximum A-MSDU size in bytes recommended by rate control.
+ * @txpwr: indicates the tx power, in mBm, to be used when sending data frames
+ * to the STA. Value of 0 means, automatic (default) tx power.
  * @txq: per-TID data TX queues (if driver uses the TXQ abstraction)
  */
 struct ieee80211_sta {
@@ -1800,6 +1802,7 @@ struct ieee80211_sta {
u16 max_amsdu_len;
bool support_p2p_ps;
u16 max_rc_amsdu_len;
+   u16 txpwr;
 
struct ieee80211_txq *txq[IEEE80211_NUM_TIDS];
 
@@ -3545,6 +3548,9 @@ struct ieee80211_ops {
 #endif
void (*sta_notify)(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
enum sta_notify_cmd, struct ieee80211_sta *sta);
+   int (*sta_set_txpwr)(struct ieee80211_hw *hw,
+struct ieee80211_vif *vif,
+struct ieee80211_sta *sta);
int (*sta_state)(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
 struct ieee80211_sta *sta,
 enum ieee80211_sta_state old_state,
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index e91e503..0084258 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1346,6 +1346,14 @@ static int sta_apply_parameters(struct ieee80211_local 
*local,
if (params->listen_interval >= 0)
sta->listen_interval = params->listen_interval;
 
+   if (params->sta_modify_mask & STATION_PARAM_APPLY_STA_TXPOWER &&
+   params->txpwr >= 0) {
+   sta->sta.txpwr = params->txpwr;
+   ret = drv_sta_set_txpwr(local, sdata, sta);
+   if (ret)
+   return ret;
+   }
+
if (params->supported_rates) {
ieee80211_parse_bitrates(>vif.bss_conf.chandef,
 sband, params->supported_rates,
diff --git a/net/mac80211/driver-ops.c b/net/mac80211/driver-ops.c
index bb886e7..839c002 100644
--- a/net/mac80211/driver-ops.c
+++ b/net/mac80211/driver-ops.c
@@ -138,6 +138,27 @@ int drv_sta_state(struct ieee80211_local *local,
return ret;
 }
 
+__must_check
+int drv_sta_set_txpwr(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
+ struct sta_info *sta)
+{
+   int ret = -EOPNOTSUPP;
+
+   might_sleep();
+
+   sdata = get_bss_sdata(sdata);
+   if (!check_sdata_in_driver(sdata))
+   return -EIO;
+
+   trace_drv_sta_set_txpwr(local, sdata, >sta);
+   if (local->ops->sta_set_txpwr)
+   ret = local->ops->sta_set_txpwr(>hw, >vif,
+   >sta);
+   trace_drv_return_int(local, ret);
+   return ret;
+}
+
 void drv_sta_rc_update(struct ieee80211_local *local,
   struct ieee80211_sub_if_data *sdata,
   struct ieee80211_sta *sta, u32 changed)
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 09f77e4..2b13c39 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -526,6 +526,11 @@ int drv_sta_state(struct ieee80211_local *local,
  enum ieee80211_sta_state old_state,
  enum ieee80211_sta_state new_state);
 
+__must_check
+int drv_sta_set_txpwr(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
+ struct sta_info *sta);
+
 void drv_sta_rc_update(struct ieee80211_local *local,
   struct ieee80211_sub_if_data *sdata,
   struct ieee80211_sta *sta, u32 changed);
diff --git a/net/mac80211/trace.h b/net/mac80211/trace.h
index 92a47af..3c505c1 100644
--- a/net/mac80211/trace.h
+++ b/net/mac80211/trace.h
@@ -823,6 +823,33 @@
)
 );
 
+TRACE_EVENT(drv_sta_set_txpwr,
+   TP_PROTO(struct ieee80211_local *local,
+struct ieee80211_sub_if_data *sdata,
+struct ieee80211_sta *sta),
+
+ 

Re: [PATCH v4 3/5] cfg80211: Accept multiple RSSI thresholds for CQM

[Andrew Zaborowski]

Hi,

On 8 February 2017 at 10:58, Johannes Berg  wrote:
>
>> This method doesn't have a hysteresis parameter because there's no
>> benefit to the cfg80211 code from having the hysteresis be handled by
>> hardware/driver in terms of the number of wakeups.  At the same time
>> it would likely be less consistent between drivers if offloaded or
>> done in the drivers.
>
> I'm not really sure I buy this.
>
> What if I configure a few ranges, and let's say one of the boundaries
> is -50dBm. Now if I sit just on that value of -50dBm and thus my signal
> fluctuates say -48..-52, I'd have to continuously wake up the host.
>
> You try to avoid that here, I think:
>
> +   if (low > (s32) (last - hyst))
> +   low = last - hyst;
> +   if (high < (s32) (last + hyst))
> +   high = last + hyst;
>
> but it's not clear to me that this is effective?
>
> Let's see. last is -52, so low will be -60 and high will be -50.
>
> Let's say hyst is 3 since I chose the ranges so closely. I'm guessing a
> higher hysteresis and larger ranges would actually be better, but let's
> stick to this for the sake of the example.
>
> last-hyst = -55, so low isn't > that, low = -60
> last+hyst = -49, so high = -49
>
> but now it still fluctuates around -50, so if I next hit -48 you do the
> same dance again with -50/-40, getting -51/-40 and never really
> applying a full hysteresis, no?
>
> I'll probably see an intermediate value of -50 at some point, but I'll
> never actually *report* it, so "last" can switch between -48 and -52
> constantly in this scenario, no?

Yes, sounds like this could happen.

>
>
> I think it would make sense to unconditionally apply the hysteresis to
> low/high, i.e. always set
>  low = low - hyst
>  high = high + hyst
>
> so that you get "sticky" ranges once you're in them?

Yes, maybe that's better, I guess I want to avoid just adding a lag /
delay in reporting changes that are not due to measurement error or
temporary.  Could also do something in between, e.g. use "low - hyst"
if signal is close to low, otherwise just "low".

The question is how the current hysteresis parameter is defined, what
is expected of the firmware and how do driver authors decide whether
their firmware/hardware implements the same mechanism as expected by
the kernel.  Would the same thing happen with firmware implementations
if the hysteresis value is 3 and the rssi fluctuates by +/- 2?  Or
would it have to be +/- 3 or +/- 4 before this starts to happen.  (If
this isn't well specified then it makes more sense to try to do it in
one place for consistency.)

>
>
>
>> + if (!wiphy_ext_feature_isset(>wiphy,
>> +
>>NL80211_EXT_FEATURE_CQM_RSSI_LIST))
>> + return
>> -EOPNOTSUPP;
>
>
> That check should be earlier in the function
> cfg80211_cqm_rssi_update(), no?

Oh looks like it can actually be removed in the current code because
nl80211_set_cqm_rssi already has this check and wdev->cqm_config can't
be set outside that function.

Best regards

[PATCH v3 1/2] cfg80211: Add support to set tx power for a station associated

[Ashok Raj Nagarajan]

This patch adds support to set transmit power setting type and transmit
power level attributes to NL80211_CMD_SET_STATION in order to facilitate
adjusting the transmit power level of a station associated to the AP.

The added attributes allow selection of automatic and limited transmit
power level, with the level defined in mBm format.

Signed-off-by: Ashok Raj Nagarajan 
---
v2:
- refactor the shared code
- "keep what you had" using STATION_PARAM_APPLY_* BIT
- feature flag to let the user know if this feature is supported or not 
(Johannes)
v3:
- fix the limitation of changing the txpwr after association (Ben 
Greear)

 include/net/cfg80211.h   |  6 ++
 include/uapi/linux/nl80211.h | 15 ++
 net/wireless/nl80211.c   | 48 
 3 files changed, 69 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 814be4b..661e0ea 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -808,6 +808,7 @@ enum station_parameters_apply_mask {
STATION_PARAM_APPLY_UAPSD = BIT(0),
STATION_PARAM_APPLY_CAPABILITY = BIT(1),
STATION_PARAM_APPLY_PLINK_STATE = BIT(2),
+   STATION_PARAM_APPLY_STA_TXPOWER = BIT(3),
 };
 
 /**
@@ -849,6 +850,10 @@ enum station_parameters_apply_mask {
  * @opmode_notif: operating mode field from Operating Mode Notification
  * @opmode_notif_used: information if operating mode field is used
  * @support_p2p_ps: information if station supports P2P PS mechanism
+ * @txpwr: tx power (in mBm) to be used for sending data traffic. If tx power
+ * is not provided, the default per-interface tx power setting will be
+ * overriding. Driver should be picking up the lowest tx power, either tx
+ * power per-interface or per-station.
  */
 struct station_parameters {
const u8 *supported_rates;
@@ -876,6 +881,7 @@ struct station_parameters {
u8 opmode_notif;
bool opmode_notif_used;
int support_p2p_ps;
+   u16 txpwr;
 };
 
 /**
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 6b76e3b..de2f72c 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1980,6 +1980,15 @@ enum nl80211_commands {
  * @NL80211_ATTR_BSSID: The BSSID of the AP. Note that %NL80211_ATTR_MAC is 
also
  * used in various commands/events for specifying the BSSID.
  *
+ * @NL80211_ATTR_STA_TX_POWER_SETTING: Transmit power setting type (u32) for
+ * station associated with the AP. See  nl80211_tx_power_setting for
+ * possible values.
+ * @NL80211_ATTR_STA_TX_POWER: Transmit power level (u32) in mBm units. This
+ * allows to set Tx power for a station. If this attribute is not included,
+ * the default per-interface tx power setting will be overriding. Driver
+ * should be picking up the lowest tx power, either tx power per-interface
+ * or per-station.
+ *
  * @NUM_NL80211_ATTR: total number of nl80211_attrs available
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2386,6 +2395,9 @@ enum nl80211_attrs {
 
NL80211_ATTR_BSSID,
 
+   NL80211_ATTR_STA_TX_POWER_SETTING,
+   NL80211_ATTR_STA_TX_POWER,
+
/* add attributes here, update the policy in nl80211.c */
 
__NL80211_ATTR_AFTER_LAST,
@@ -4697,6 +4709,8 @@ enum nl80211_feature_flags {
  * configuration (AP/mesh) with VHT rates.
  * @NL80211_EXT_FEATURE_FILS_STA: This driver supports Fast Initial Link Setup
  * with user space SME (NL80211_CMD_AUTHENTICATE) in station mode.
+ * @NL80211_EXT_FEATURE_STA_TX_PWR: This driver supports controlling tx power
+ * to a station.
  *
  * @NUM_NL80211_EXT_FEATURES: number of extended features.
  * @MAX_NL80211_EXT_FEATURES: highest extended feature index.
@@ -4712,6 +4726,7 @@ enum nl80211_ext_feature_index {
NL80211_EXT_FEATURE_BEACON_RATE_HT,
NL80211_EXT_FEATURE_BEACON_RATE_VHT,
NL80211_EXT_FEATURE_FILS_STA,
+   NL80211_EXT_FEATURE_STA_TX_PWR,
 
/* add new features before the definition below */
NUM_NL80211_EXT_FEATURES,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ef5eff93..701c08a 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -246,6 +246,8 @@ enum nl80211_multicast_groups {
[NL80211_ATTR_STA_SUPPORTED_RATES] = { .type = NLA_BINARY,
   .len = NL80211_MAX_SUPP_RATES },
[NL80211_ATTR_STA_PLINK_ACTION] = { .type = NLA_U8 },
+   [NL80211_ATTR_STA_TX_POWER_SETTING] = { .type = NLA_U32 },
+   [NL80211_ATTR_STA_TX_POWER] = { .type = NLA_U32 },
[NL80211_ATTR_STA_VLAN] = { .type = NLA_U32 },
[NL80211_ATTR_MNTR_FLAGS] = { /* NLA_NESTED can't be empty */ },
[NL80211_ATTR_MESH_ID] = { .type = NLA_BINARY,
@@ -4755,6 +4757,40 @@ static int nl80211_set_station_tdls(struct 

[PATCH 2/2] rt2x00usb: fix anchor initialization

[Stanislaw Gruszka]

If device fail to initialize we can OOPS in rt2x00lib_remove_dev(), due
to using uninitialized usb_anchor structure:

[  855.435820] ieee80211 phy3: rt2x00usb_vendor_request: Error - Vendor Request 
0x07 failed for offset 0x1000 with error -19
[  855.435826] ieee80211 phy3: rt2800_probe_rt: Error - Invalid RT chipset 
0x, rev  detected
[  855.435829] ieee80211 phy3: rt2x00lib_probe_dev: Error - Failed to allocate 
device
[  855.435845] BUG: unable to handle kernel NULL pointer dereference at 
0028
[  855.435900] IP: _raw_spin_lock_irq+0xd/0x30
[  855.435926] PGD 0
[  855.435953] Oops: 0002 [#1] SMP

[  855.437011] Call Trace:
[  855.437029]  ? usb_kill_anchored_urbs+0x27/0xc0
[  855.437061]  rt2x00lib_remove_dev+0x190/0x1c0 [rt2x00lib]
[  855.437097]  rt2x00lib_probe_dev+0x246/0x7a0 [rt2x00lib]
[  855.437149]  ? ieee80211_roc_setup+0x9e/0xd0 [mac80211]
[  855.437183]  ? __kmalloc+0x1af/0x1f0
[  855.437207]  ? rt2x00usb_probe+0x13d/0xc50 [rt2x00usb]
[  855.437240]  rt2x00usb_probe+0x155/0xc50 [rt2x00usb]
[  855.437273]  rt2800usb_probe+0x15/0x20 [rt2800usb]
[  855.437304]  usb_probe_interface+0x159/0x2d0
[  855.437333]  driver_probe_device+0x2bb/0x460

Patch changes initialization sequence to fix the problem.

Cc: Vishal Thanki 
Fixes: 8b4c0009313f ("rt2x00usb: Use usb anchor to manage URB")
Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c 
b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
index fe13dd0..c696f0a 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
@@ -825,10 +825,6 @@ int rt2x00usb_probe(struct usb_interface *usb_intf,
if (retval)
goto exit_free_device;
 
-   retval = rt2x00lib_probe_dev(rt2x00dev);
-   if (retval)
-   goto exit_free_reg;
-
rt2x00dev->anchor = devm_kmalloc(_dev->dev,
sizeof(struct usb_anchor),
GFP_KERNEL);
@@ -836,10 +832,17 @@ int rt2x00usb_probe(struct usb_interface *usb_intf,
retval = -ENOMEM;
goto exit_free_reg;
}
-
init_usb_anchor(rt2x00dev->anchor);
+
+   retval = rt2x00lib_probe_dev(rt2x00dev);
+   if (retval)
+   goto exit_free_anchor;
+
return 0;
 
+exit_free_anchor:
+   usb_kill_anchored_urbs(rt2x00dev->anchor);
+
 exit_free_reg:
rt2x00usb_free_reg(rt2x00dev);
 
-- 
1.8.3.1

[PATCH 1/2] rt2x00usb: do not anchor rx and tx urb's

[Stanislaw Gruszka]

We might kill TX or RX urb during rt2x00usb_flush_entry(), what can
cause anchor list corruption like shown below:

[ 2074.035633] WARNING: CPU: 2 PID: 14480 at lib/list_debug.c:33 
__list_add+0xac/0xc0
[ 2074.035634] list_add corruption. prev->next should be next 
(88020f362c28), but was dead0100. (prev=8801d161bb70).

[ 2074.035670] Call Trace:
[ 2074.035672]  [] dump_stack+0x63/0x8c
[ 2074.035674]  [] __warn+0xd1/0xf0
[ 2074.035676]  [] warn_slowpath_fmt+0x5f/0x80
[ 2074.035678]  [] ? rt2x00usb_register_write_lock+0x3d/0x60 
[rt2800usb]
[ 2074.035679]  [] __list_add+0xac/0xc0
[ 2074.035681]  [] usb_anchor_urb+0x4c/0xa0
[ 2074.035683]  [] rt2x00usb_kick_rx_entry+0xaf/0x100 
[rt2x00usb]
[ 2074.035684]  [] rt2x00usb_clear_entry+0x22/0x30 [rt2x00usb]

To fix do not anchor TX and RX urb's, it is not needed as during
shutdown we kill those urbs in rt2x00usb_free_entries().

Cc: Vishal Thanki 
Fixes: 8b4c0009313f ("rt2x00usb: Use usb anchor to manage URB")
Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c 
b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
index 5a2bf9f..fe13dd0 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
@@ -319,10 +319,8 @@ static bool rt2x00usb_kick_tx_entry(struct queue_entry 
*entry, void *data)
  entry->skb->data, length,
  rt2x00usb_interrupt_txdone, entry);
 
-   usb_anchor_urb(entry_priv->urb, rt2x00dev->anchor);
status = usb_submit_urb(entry_priv->urb, GFP_ATOMIC);
if (status) {
-   usb_unanchor_urb(entry_priv->urb);
if (status == -ENODEV)
clear_bit(DEVICE_STATE_PRESENT, >flags);
set_bit(ENTRY_DATA_IO_FAILED, >flags);
@@ -410,10 +408,8 @@ static bool rt2x00usb_kick_rx_entry(struct queue_entry 
*entry, void *data)
  entry->skb->data, entry->skb->len,
  rt2x00usb_interrupt_rxdone, entry);
 
-   usb_anchor_urb(entry_priv->urb, rt2x00dev->anchor);
status = usb_submit_urb(entry_priv->urb, GFP_ATOMIC);
if (status) {
-   usb_unanchor_urb(entry_priv->urb);
if (status == -ENODEV)
clear_bit(DEVICE_STATE_PRESENT, >flags);
set_bit(ENTRY_DATA_IO_FAILED, >flags);
-- 
1.8.3.1

[PATCH 07/17] iwlwifi: mvm: fix reorder timer re-arming

[Luca Coelho]

From: Sara Sharon 

When NSSN is behind the reorder buffer due to timeout
the reorder timer isn't getting re-armed until NSSN
catches up. Fix it.

Fixes: 0690405fef29 ("iwlwifi: mvm: add reorder timeout per frame")

Signed-off-by: Sara Sharon 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
index c154ab42c80d..d79e9c2a2654 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
@@ -418,7 +418,7 @@ static void iwl_mvm_release_frames(struct iwl_mvm *mvm,
 
/* ignore nssn smaller than head sn - this can happen due to timeout */
if (iwl_mvm_is_sn_less(nssn, ssn, reorder_buf->buf_size))
-   return;
+   goto set_timer;
 
while (iwl_mvm_is_sn_less(ssn, nssn, reorder_buf->buf_size)) {
int index = ssn % reorder_buf->buf_size;
@@ -441,6 +441,7 @@ static void iwl_mvm_release_frames(struct iwl_mvm *mvm,
}
reorder_buf->head_sn = nssn;
 
+set_timer:
if (reorder_buf->num_stored && !reorder_buf->removed) {
u16 index = reorder_buf->head_sn % reorder_buf->buf_size;
 
-- 
2.11.0

[PATCH 05/17] iwlwifi: mvm: fix a print of NSS for HT rate

[Luca Coelho]

From: Gregory Greenman 

Handling of the number of space time streams was missing for HT rate in
rate printing function. Fix it.

Signed-off-by: Gregory Greenman 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
index 80f99c365b6a..13be9a5b83ee 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
@@ -3616,6 +3616,8 @@ int rs_pretty_print_rate(char *buf, const u32 rate)
} else if (rate & RATE_MCS_HT_MSK) {
type = "HT";
mcs = rate & RATE_HT_MCS_INDEX_MSK;
+   nss = ((rate & RATE_HT_MCS_NSS_MSK)
+  >> RATE_HT_MCS_NSS_POS) + 1;
} else {
type = "Unknown"; /* shouldn't happen */
}
-- 
2.11.0

[PATCH 00/17] iwlwifi: updates intended for v4.11 2017-02-08

[Luca Coelho]

From: Luca Coelho 

Hi,

This is the third and final pull-request before 4.11's merge window.
This time I concentrated in bugfixes:

* Fix 802.11w, which was failing to due an IGTK bug;
* A few more bugzilla bug fixes;
* A channel-switch race condition fix;
* Some fixes related to suspend/resume with new HW;
* The RF-kill saga continues;
* And some other fixes here and there...

As usual, I'm pushing this to a pending branch, for kbuild bot, and
will send a pull-request later.

Please review.

Cheers,
Luca.


Avraham Stern (1):
  iwlwifi: mvm: Fix CSA received immediately after association

Emmanuel Grumbach (5):
  iwlwifi: mvm: use the PROBE_RESP_QUEUE to send deauth to unknown
station
  iwlwifi: pcie: don't increment / decrement a bool
  iwlwifi: make RTPM depend on EXPERT
  iwlwifi: dvm: don't call << operator with a negative value
  iwlwifi: mvm: don't call << operator with a negative value

Golan Ben Ami (2):
  iwlwifi: pcie: Re-configure IVAR table after stop device
  iwlwifi: pcie: set STATUS_RFKILL immediately after interrupt

Golan Ben-Ami (1):
  iwlwifi: mvm: avoid exceeding the allowed print length

Goodstein, Mordechay (1):
  iwlwifi: mvm: avoid race condition in ADD_STA.

Gregory Greenman (1):
  iwlwifi: mvm: fix a print of NSS for HT rate

Haim Dreyfuss (3):
  iwlwifi: pcie: move msix conf functions above other functions
  iwlwifi: pcie: separate between SW and HW MSIX configuration
  iwlwifi: pcie: re-configure IVAR table after suspend-resume

Ilan Peer (1):
  iwlwifi: mvm: Fix removal of IGTK

Sara Sharon (2):
  iwlwifi: mvm: fix references to first_agg_queue in DQA mode
  iwlwifi: mvm: fix reorder timer re-arming

 drivers/net/wireless/intel/iwlwifi/Kconfig |   7 +-
 drivers/net/wireless/intel/iwlwifi/dvm/rs.c|   5 +-
 drivers/net/wireless/intel/iwlwifi/mvm/fw.c|  20 +-
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c  |  15 +-
 drivers/net/wireless/intel/iwlwifi/mvm/rs.c|   6 +-
 drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c  |   3 +-
 drivers/net/wireless/intel/iwlwifi/mvm/sta.c   |   7 +-
 drivers/net/wireless/intel/iwlwifi/mvm/tx.c|  17 +-
 drivers/net/wireless/intel/iwlwifi/pcie/internal.h |   2 +-
 drivers/net/wireless/intel/iwlwifi/pcie/rx.c   |   8 +-
 drivers/net/wireless/intel/iwlwifi/pcie/trans.c| 243 -
 11 files changed, 188 insertions(+), 145 deletions(-)

-- 
2.11.0

[PATCH 04/17] iwlwifi: pcie: Re-configure IVAR table after stop device

[Luca Coelho]

From: Golan Ben Ami 

When getting RF_KILL and disabling radio, the device gets stopped
and reset. This erases the IVAR table that matches the interrupt
to its cause, and is essential for MSIX proper functionality.
Till now, the table wasn't re-configured after the reset, and
therefore the interrupt that enabled radio didn't fire on the
right irq, and the driver didn't handle it correctly.

To fix this, configure the IVAR table again after resetting the
device.

Signed-off-by: Golan Ben-Ami 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c 
b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index bb2a9a151957..7f05fc56587a 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -1246,6 +1246,15 @@ static void _iwl_trans_pcie_stop_device(struct iwl_trans 
*trans, bool low_power)
usleep_range(1000, 2000);
 
/*
+* Upon stop, the IVAR table gets erased, so msi-x won't
+* work. This causes a bug in RF-KILL flows, since the interrupt
+* that enables radio won't fire on the correct irq, and the
+* driver won't be able to handle the interrupt.
+* Configure the IVAR table again after reset.
+*/
+   iwl_pcie_conf_msix_hw(trans_pcie);
+
+   /*
 * Upon stop, the APM issues an interrupt if HW RF kill is set.
 * This is a bug in certain verions of the hardware.
 * Certain devices also keep sending HW RF kill interrupt all
-- 
2.11.0

[PATCH 02/17] iwlwifi: pcie: separate between SW and HW MSIX configuration

[Luca Coelho]

From: Haim Dreyfuss 

The MSIX configuration flow includes two different stages:
configuring the HW by writing to the IVAR table and configuring the SW
to reflect the HW configuration.
The HW configuration is needed on each HW reset,
whereas the SW configuration is only needed during the init flow.

Signed-off-by: Haim Dreyfuss 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c 
b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index f795ebea4c4a..e7a26f594386 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -1147,7 +1147,7 @@ static void iwl_pcie_map_rx_causes(struct iwl_trans 
*trans)
iwl_write8(trans, CSR_MSIX_RX_IVAR(1), val);
 }
 
-static void iwl_pcie_init_msix(struct iwl_trans_pcie *trans_pcie)
+static void iwl_pcie_conf_msix_hw(struct iwl_trans_pcie *trans_pcie)
 {
struct iwl_trans *trans = trans_pcie->trans;
 
@@ -1170,12 +1170,20 @@ static void iwl_pcie_init_msix(struct iwl_trans_pcie 
*trans_pcie)
iwl_pcie_map_rx_causes(trans);
 
iwl_pcie_map_non_rx_causes(trans);
+}
+
+static void iwl_pcie_init_msix(struct iwl_trans_pcie *trans_pcie)
+{
+   struct iwl_trans *trans = trans_pcie->trans;
+
+   iwl_pcie_conf_msix_hw(trans_pcie);
 
-   trans_pcie->fh_init_mask =
-   ~iwl_read32(trans, CSR_MSIX_FH_INT_MASK_AD);
+   if (!trans_pcie->msix_enabled)
+   return;
+
+   trans_pcie->fh_init_mask = ~iwl_read32(trans, CSR_MSIX_FH_INT_MASK_AD);
trans_pcie->fh_mask = trans_pcie->fh_init_mask;
-   trans_pcie->hw_init_mask =
-   ~iwl_read32(trans, CSR_MSIX_HW_INT_MASK_AD);
+   trans_pcie->hw_init_mask = ~iwl_read32(trans, CSR_MSIX_HW_INT_MASK_AD);
trans_pcie->hw_mask = trans_pcie->hw_init_mask;
 }
 
@@ -1675,6 +1683,7 @@ static int _iwl_trans_pcie_start_hw(struct iwl_trans 
*trans, bool low_power)
iwl_pcie_apm_init(trans);
 
iwl_pcie_init_msix(trans_pcie);
+
/* From now on, the op_mode will be kept updated about RF kill state */
iwl_enable_rfkill_int(trans);
 
-- 
2.11.0

[PATCH 08/17] iwlwifi: mvm: use the PROBE_RESP_QUEUE to send deauth to unknown station

[Luca Coelho]

From: Emmanuel Grumbach 

When we send a deauth to a station we don't know about, we
need to use the PROBE_RESP queue. This can happen when we
send a deauth to a station that is not associated to us.

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
index 1d147599cca9..dd2b4a300819 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@ -506,15 +506,17 @@ static int iwl_mvm_get_ctrl_vif_queue(struct iwl_mvm *mvm,
switch (info->control.vif->type) {
case NL80211_IFTYPE_AP:
/*
-* handle legacy hostapd as well, where station may be added
-* only after assoc.
+* Handle legacy hostapd as well, where station may be added
+* only after assoc. Take care of the case where we send a
+* deauth to a station that we don't have.
 */
-   if (ieee80211_is_probe_resp(fc) || ieee80211_is_auth(fc))
+   if (ieee80211_is_probe_resp(fc) || ieee80211_is_auth(fc) ||
+   ieee80211_is_deauth(fc))
return IWL_MVM_DQA_AP_PROBE_RESP_QUEUE;
if (info->hw_queue == info->control.vif->cab_queue)
return info->hw_queue;
 
-   WARN_ON_ONCE(1);
+   WARN_ONCE(1, "fc=0x%02x", le16_to_cpu(fc));
return IWL_MVM_DQA_AP_PROBE_RESP_QUEUE;
case NL80211_IFTYPE_P2P_DEVICE:
if (ieee80211_is_mgmt(fc))
-- 
2.11.0

[PATCH 03/17] iwlwifi: pcie: re-configure IVAR table after suspend-resume

[Luca Coelho]

From: Haim Dreyfuss 

During the suspend/resume flow some HW blocks are reset.  This causes
the IVAR table to be completely erased.  This table is where interrupt
causes are bound to specific IRQs.  When the table is empty the
interrupt handlers are not called correctly.  Fix this by reconfiguring
the IVAR table after resume.

Fixes: 2e5d4a8f61dc ("iwlwifi: pcie: Add new configuration to enable MSIX")
Signed-off-by: Haim Dreyfuss 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c 
b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index e7a26f594386..bb2a9a151957 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -1152,13 +1152,19 @@ static void iwl_pcie_conf_msix_hw(struct iwl_trans_pcie 
*trans_pcie)
struct iwl_trans *trans = trans_pcie->trans;
 
if (!trans_pcie->msix_enabled) {
-   if (trans->cfg->mq_rx_supported)
+   if (trans->cfg->mq_rx_supported &&
+   test_bit(STATUS_DEVICE_ENABLED, >status))
iwl_write_prph(trans, UREG_CHICK,
   UREG_CHICK_MSI_ENABLE);
return;
}
-
-   iwl_write_prph(trans, UREG_CHICK, UREG_CHICK_MSIX_ENABLE);
+   /*
+* The IVAR table needs to be configured again after reset,
+* but if the device is disabled, we can't write to
+* prph.
+*/
+   if (test_bit(STATUS_DEVICE_ENABLED, >status))
+   iwl_write_prph(trans, UREG_CHICK, UREG_CHICK_MSIX_ENABLE);
 
/*
 * Each cause from the causes list above and the RX causes is
@@ -1457,6 +1463,7 @@ static int iwl_trans_pcie_d3_resume(struct iwl_trans 
*trans,
enum iwl_d3_status *status,
bool test,  bool reset)
 {
+   struct iwl_trans_pcie *trans_pcie =  IWL_TRANS_GET_PCIE_TRANS(trans);
u32 val;
int ret;
 
@@ -1469,11 +1476,15 @@ static int iwl_trans_pcie_d3_resume(struct iwl_trans 
*trans,
iwl_pcie_enable_rx_wake(trans, true);
 
/*
-* Also enables interrupts - none will happen as the device doesn't
-* know we're waking it up, only when the opmode actually tells it
-* after this call.
+* Reconfigure IVAR table in case of MSIX or reset ict table in
+* MSI mode since HW reset erased it.
+* Also enables interrupts - none will happen as
+* the device doesn't know we're waking it up, only when
+* the opmode actually tells it after this call.
 */
-   iwl_pcie_reset_ict(trans);
+   iwl_pcie_conf_msix_hw(trans_pcie);
+   if (!trans_pcie->msix_enabled)
+   iwl_pcie_reset_ict(trans);
iwl_enable_interrupts(trans);
 
iwl_set_bit(trans, CSR_GP_CNTRL, CSR_GP_CNTRL_REG_FLAG_MAC_ACCESS_REQ);
-- 
2.11.0

[PATCH 01/17] iwlwifi: pcie: move msix conf functions above other functions

[Luca Coelho]

From: Haim Dreyfuss 

msix configuration functions should be called by other functions.
For example by pcie_d3_resume, move it above to enable it.

Signed-off-by: Haim Dreyfuss 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 206 
 1 file changed, 103 insertions(+), 103 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c 
b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index b28d99f61a35..f795ebea4c4a 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -1076,6 +1076,109 @@ static bool iwl_trans_check_hw_rf_kill(struct iwl_trans 
*trans)
return hw_rfkill;
 }
 
+struct iwl_causes_list {
+   u32 cause_num;
+   u32 mask_reg;
+   u8 addr;
+};
+
+static struct iwl_causes_list causes_list[] = {
+   {MSIX_FH_INT_CAUSES_D2S_CH0_NUM,CSR_MSIX_FH_INT_MASK_AD, 0},
+   {MSIX_FH_INT_CAUSES_D2S_CH1_NUM,CSR_MSIX_FH_INT_MASK_AD, 0x1},
+   {MSIX_FH_INT_CAUSES_S2D,CSR_MSIX_FH_INT_MASK_AD, 0x3},
+   {MSIX_FH_INT_CAUSES_FH_ERR, CSR_MSIX_FH_INT_MASK_AD, 0x5},
+   {MSIX_HW_INT_CAUSES_REG_ALIVE,  CSR_MSIX_HW_INT_MASK_AD, 0x10},
+   {MSIX_HW_INT_CAUSES_REG_WAKEUP, CSR_MSIX_HW_INT_MASK_AD, 0x11},
+   {MSIX_HW_INT_CAUSES_REG_CT_KILL,CSR_MSIX_HW_INT_MASK_AD, 0x16},
+   {MSIX_HW_INT_CAUSES_REG_RF_KILL,CSR_MSIX_HW_INT_MASK_AD, 0x17},
+   {MSIX_HW_INT_CAUSES_REG_PERIODIC,   CSR_MSIX_HW_INT_MASK_AD, 0x18},
+   {MSIX_HW_INT_CAUSES_REG_SW_ERR, CSR_MSIX_HW_INT_MASK_AD, 0x29},
+   {MSIX_HW_INT_CAUSES_REG_SCD,CSR_MSIX_HW_INT_MASK_AD, 0x2A},
+   {MSIX_HW_INT_CAUSES_REG_FH_TX,  CSR_MSIX_HW_INT_MASK_AD, 0x2B},
+   {MSIX_HW_INT_CAUSES_REG_HW_ERR, CSR_MSIX_HW_INT_MASK_AD, 0x2D},
+   {MSIX_HW_INT_CAUSES_REG_HAP,CSR_MSIX_HW_INT_MASK_AD, 0x2E},
+};
+
+static void iwl_pcie_map_non_rx_causes(struct iwl_trans *trans)
+{
+   struct iwl_trans_pcie *trans_pcie =  IWL_TRANS_GET_PCIE_TRANS(trans);
+   int val = trans_pcie->def_irq | MSIX_NON_AUTO_CLEAR_CAUSE;
+   int i;
+
+   /*
+* Access all non RX causes and map them to the default irq.
+* In case we are missing at least one interrupt vector,
+* the first interrupt vector will serve non-RX and FBQ causes.
+*/
+   for (i = 0; i < ARRAY_SIZE(causes_list); i++) {
+   iwl_write8(trans, CSR_MSIX_IVAR(causes_list[i].addr), val);
+   iwl_clear_bit(trans, causes_list[i].mask_reg,
+ causes_list[i].cause_num);
+   }
+}
+
+static void iwl_pcie_map_rx_causes(struct iwl_trans *trans)
+{
+   struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
+   u32 offset =
+   trans_pcie->shared_vec_mask & IWL_SHARED_IRQ_FIRST_RSS ? 1 : 0;
+   u32 val, idx;
+
+   /*
+* The first RX queue - fallback queue, which is designated for
+* management frame, command responses etc, is always mapped to the
+* first interrupt vector. The other RX queues are mapped to
+* the other (N - 2) interrupt vectors.
+*/
+   val = BIT(MSIX_FH_INT_CAUSES_Q(0));
+   for (idx = 1; idx < trans->num_rx_queues; idx++) {
+   iwl_write8(trans, CSR_MSIX_RX_IVAR(idx),
+  MSIX_FH_INT_CAUSES_Q(idx - offset));
+   val |= BIT(MSIX_FH_INT_CAUSES_Q(idx));
+   }
+   iwl_write32(trans, CSR_MSIX_FH_INT_MASK_AD, ~val);
+
+   val = MSIX_FH_INT_CAUSES_Q(0);
+   if (trans_pcie->shared_vec_mask & IWL_SHARED_IRQ_NON_RX)
+   val |= MSIX_NON_AUTO_CLEAR_CAUSE;
+   iwl_write8(trans, CSR_MSIX_RX_IVAR(0), val);
+
+   if (trans_pcie->shared_vec_mask & IWL_SHARED_IRQ_FIRST_RSS)
+   iwl_write8(trans, CSR_MSIX_RX_IVAR(1), val);
+}
+
+static void iwl_pcie_init_msix(struct iwl_trans_pcie *trans_pcie)
+{
+   struct iwl_trans *trans = trans_pcie->trans;
+
+   if (!trans_pcie->msix_enabled) {
+   if (trans->cfg->mq_rx_supported)
+   iwl_write_prph(trans, UREG_CHICK,
+  UREG_CHICK_MSI_ENABLE);
+   return;
+   }
+
+   iwl_write_prph(trans, UREG_CHICK, UREG_CHICK_MSIX_ENABLE);
+
+   /*
+* Each cause from the causes list above and the RX causes is
+* represented as a byte in the IVAR table. The first nibble
+* represents the bound interrupt vector of the cause, the second
+* represents no auto clear for this cause. This will be set if its
+* interrupt vector is bound to serve other causes.
+*/
+   iwl_pcie_map_rx_causes(trans);
+
+   iwl_pcie_map_non_rx_causes(trans);
+
+   trans_pcie->fh_init_mask =
+   

[PATCH 06/17] iwlwifi: mvm: fix references to first_agg_queue in DQA mode

[Luca Coelho]

From: Sara Sharon 

In DQA mode, first_agg_queue is initialized to
IWL_MVM_DQA_MIN_DATA_QUEUE. This causes two bugs in the tx response
flow:

1. When TX fails, we set IEEE80211_TX_STAT_AMPDU_NO_BACK regardless
   if we actually have aggregation open on the queue. This causes
   mac80211 to send a BAR frame even though there is no aggregation
   open.
   Fix that by simply checking the AMPDU flag that is set on by
   mac80211 for AMPDU packets.

2. When reclaiming frames in aggregation mode, we reclaim based on
   scheduler ssn and not the SN.
   The reason is that scheduler ssn may be ahead of SN due to a hole
   in the BA window that was filled.
   However, if we have aggregations open on IWL_MVM_DQA_BSS_CLIENT_QUEUE
   the reclaim flow will still go to the code of non-aggregation
   instead of the aggregation code since IWL_MVM_DQA_BSS_CLIENT_QUEUE
   is smaller than IWL_MVM_DQA_MIN_DATA_QUEUE, although it is a valid
   aggregation queue.
   Fix that by always using the aggregation reclaim code by default in
   DQA mode (currently it is implicitly used by default for all queues
   except the reserved BSS queue).

Fixes: cf961e16620f ("iwlwifi: mvm: support dqa-mode agg on non-shared queue")
Signed-off-by: Sara Sharon 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
index 4ba639eda7a3..1d147599cca9 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@ -1274,8 +1274,6 @@ static void iwl_mvm_rx_tx_cmd_single(struct iwl_mvm *mvm,
 
memset(>status, 0, sizeof(info->status));
 
-   info->flags &= ~IEEE80211_TX_CTL_AMPDU;
-
/* inform mac80211 about what happened with the frame */
switch (status & TX_STATUS_MSK) {
case TX_STATUS_SUCCESS:
@@ -1298,10 +1296,11 @@ static void iwl_mvm_rx_tx_cmd_single(struct iwl_mvm 
*mvm,
(void *)(uintptr_t)le32_to_cpu(tx_resp->initial_rate);
 
/* Single frame failure in an AMPDU queue => send BAR */
-   if (txq_id >= mvm->first_agg_queue &&
+   if (info->flags & IEEE80211_TX_CTL_AMPDU &&
!(info->flags & IEEE80211_TX_STAT_ACK) &&
!(info->flags & IEEE80211_TX_STAT_TX_FILTERED))
info->flags |= IEEE80211_TX_STAT_AMPDU_NO_BACK;
+   info->flags &= ~IEEE80211_TX_CTL_AMPDU;
 
/* W/A FW bug: seq_ctl is wrong when the status isn't success */
if (status != TX_STATUS_SUCCESS) {
@@ -1336,7 +1335,7 @@ static void iwl_mvm_rx_tx_cmd_single(struct iwl_mvm *mvm,
ieee80211_tx_status(mvm->hw, skb);
}
 
-   if (txq_id >= mvm->first_agg_queue) {
+   if (iwl_mvm_is_dqa_supported(mvm) || txq_id >= mvm->first_agg_queue) {
/* If this is an aggregation queue, we use the ssn since:
 * ssn = wifi seq_num % 256.
 * The seq_ctl is the sequence control of the packet to which
-- 
2.11.0

Re: [PATCH net] brcmfmac: clear skb head state on xmit

[Arend Van Spriel]

On 8-2-2017 10:29, Paolo Abeni wrote:
> On Wed, 2017-02-08 at 09:52 +0100, Rafał Miłecki wrote:
>> On 8 February 2017 at 09:38, Paolo Abeni  wrote:
>>> On Tue, 2017-02-07 at 20:23 +0100, Arend Van Spriel wrote:
 On 7-2-2017 17:50, Paolo Abeni wrote:
> the skbs can be held by the driver for a long time, so we need
> to clear any state on xmit to avoid hanging other subsystems.
> The skbs are already orphaned later in cmsg code, so we just
> need to clear the nf/dst/secpath.
> Do it early, while the relevant entries are hopefully still
> hot in the cache.

 What is this about really? A bit more background about the issue
 might
 help understanding the need for this patch. Is this really
 specific
 to
 brcmfmac. For instance is something similar already done in
 mac80211?
>>>
>>> The issue is apparently driver specific, as reported in:
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1294415
>>>
>>> This is caused by xmit skbs carrying a notrack ct entry not being
>>> freed
>>> by the device driver in a timely manner. Removing the ct module
>>> waits
>>> for such entries refcount going to zero and hangs the kernel in
>>> busy
>>> loop (for several minutes).
>>>
>>> The relevant skbs are icmp6 packets (ND if I recall correctly, they
>>> bcast packets at the mac level).
>>>
>>> The only other known device driver suffering for the issue is the
>>> infiniband ipoib driver, I send a separate patch for it.
>>>
>>> I lack the broadcom h/w, but with infiniband the bug can be
>>> reproduced
>>> with the following steps:
>>>
>>> - ensure ipv6 is enabled on the target device, and firewalld is
>>> running
>>> (e.g. the module nf_conntrack_ipv6 is loaded)
>>> - assign a static ip to the device
>>> - shut down the firewall (e.g. try to remove the module
>>> nf_conntrack)
>>>
>>> For the brcmfmac driver most probably it is necessary being
>>> disassociated from the AP before shutting down the firewall (but I
>>> can't double check). This is probably why mac80211 does not suffer
>>> this
>>> issue.
>>>
>>> The root cause for the issue could be actually a firmware issue,
>>> any
>>> better clues are more than welcome!
>>
>> Do I get this correctly brcmfmac gets some skb for transmitting it
>> and
>> doesn't free it for few minutes? It sounds like some bug that should
>> be fixed instead of hiding it.
> 
> I mostly agreed, but please also note that early clearing the skb head
> state makes sense from a performance pov: we can do the costly,
> required, atomic operations while the data is still hot in the cpu L1
> cache.
> 
> I'm unable to find anything obvious at the driver level, and I think
> the root cause could be in the firmware. I hope some more knowledgeable
> than me on this topics can have a better look.

Hi Paolo,

I agree with Rafał that several minutes for an skb to be freed is a red
flag. Now I know our driver and firmware but not played to much with
IPv6 and firewalls. Hopefully I have all the netfilter stuff in my
kernel when I try to reproduce it over here.

Regards,
Arend

Re: [PATCH V3 4/9] brcmfmac: add struct brcmf_pub parameter to the __brcmf_err

[Arend Van Spriel]

On 2-2-2017 22:33, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> This will allow getting struct device reference from the passed
> brcmf_pub for the needs of dev_err. More detailed messages are really
> important for home routers which frequently have 2 (or even 3) wireless
> cards supported by brcmfmac.
> 
> Note that all calls are yet to be updated as for now brcmf_err macro
> always passes NULL. This will be handled in following patch to make this
> change easier to review.

I prefer brcmf_err() to have struct device reference directly instead of
using brcmf_pub. That would remove the need for patches 5 till 7 as bus
specific code already has struct device. So I have acked the first three
patches, but would like to revise 8 and 9.

Kalle,

I acked the first three patches. Can those three still go in for 4.11?

Regards,
Arend
> Signed-off-by: Rafał Miłecki 
> ---
> V2: Add missing include
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h| 2 ++
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c | 2 +-
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h  | 9 +
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c | 4 +++-
>  4 files changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> index 76693df34742..35d4801a62e6 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> @@ -17,6 +17,8 @@
>  #ifndef BRCMFMAC_BUS_H
>  #define BRCMFMAC_BUS_H
>  
> +#include 
> +
>  #include "debug.h"
>  
>  /* IDs of the 6 default common rings of msgbuf protocol */
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> index 33b133f7e63a..f8ce597c4781 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> @@ -219,7 +219,7 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
>  }
>  
>  #ifndef CONFIG_BRCM_TRACING
> -void __brcmf_err(const char *func, const char *fmt, ...)
> +void __brcmf_err(struct brcmf_pub *pub, const char *func, const char *fmt, 
> ...)
>  {
>   struct va_format vaf;
>   va_list args;
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> index 066126123e96..99acc095c834 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> @@ -19,6 +19,8 @@
>  
>  #include/* net_ratelimit() */
>  
> +struct brcmf_pub;
> +
>  /* message levels */
>  #define BRCMF_TRACE_VAL  0x0002
>  #define BRCMF_INFO_VAL   0x0004
> @@ -45,8 +47,8 @@
>  #undef pr_fmt
>  #define pr_fmt(fmt)  KBUILD_MODNAME ": " fmt
>  
> -__printf(2, 3)
> -void __brcmf_err(const char *func, const char *fmt, ...);
> +__printf(3, 4)
> +void __brcmf_err(struct brcmf_pub *pub, const char *func, const char *fmt, 
> ...);
>  /* Macro for error messages. When debugging / tracing the driver all error
>   * messages are important to us.
>   */
> @@ -55,7 +57,7 @@ void __brcmf_err(const char *func, const char *fmt, ...);
>   if (IS_ENABLED(CONFIG_BRCMDBG) ||   \
>   IS_ENABLED(CONFIG_BRCM_TRACING) ||  \
>   net_ratelimit())\
> - __brcmf_err(__func__, fmt, ##__VA_ARGS__);  \
> + __brcmf_err(NULL, __func__, fmt, ##__VA_ARGS__);\
>   } while (0)
>  
>  #if defined(DEBUG) || defined(CONFIG_BRCM_TRACING)
> @@ -99,7 +101,6 @@ do {   
> \
>  
>  extern int brcmf_msg_level;
>  
> -struct brcmf_pub;
>  #ifdef DEBUG
>  void brcmf_debugfs_init(void);
>  void brcmf_debugfs_exit(void);
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c
> index fe6755944b7b..329cb65eb78b 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c
> @@ -18,10 +18,12 @@
>  
>  #ifndef __CHECKER__
>  #define CREATE_TRACE_POINTS
> +#include "bus.h"
> +#include "core.h"
>  #include "tracepoint.h"
>  #include "debug.h"
>  
> -void __brcmf_err(const char *func, const char *fmt, ...)
> +void __brcmf_err(struct brcmf_pub *pub, const char *func, const char *fmt, 
> ...)
>  {
>   struct va_format vaf = {
>   .fmt = fmt,
> 

Re: [PATCH V3 3/9] brcmfmac: merge two remaining brcmf_err macros

[Arend Van Spriel]

On 2-2-2017 22:33, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Now we always have __brcmf_err function we can do perfectly fine with
> just one macro.

Acked-by: Arend van Spriel 
> Signed-off-by: Rafał Miłecki 
> ---
> V3: Add this (new) patch
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h | 14 +-
>  1 file changed, 5 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> index 441a6661eac0..066126123e96 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> @@ -47,20 +47,16 @@
>  
>  __printf(2, 3)
>  void __brcmf_err(const char *func, const char *fmt, ...);
> -#ifndef CONFIG_BRCM_TRACING
> -/* Macro for error messages. net_ratelimit() is used when driver
> - * debugging is not selected. When debugging the driver error
> - * messages are as important as other tracing or even more so.
> +/* Macro for error messages. When debugging / tracing the driver all error
> + * messages are important to us.
>   */
>  #define brcmf_err(fmt, ...)  \
>   do {\
> - if (IS_ENABLED(CONFIG_BRCMDBG) || net_ratelimit())  \
> + if (IS_ENABLED(CONFIG_BRCMDBG) ||   \
> + IS_ENABLED(CONFIG_BRCM_TRACING) ||  \
> + net_ratelimit())\
>   __brcmf_err(__func__, fmt, ##__VA_ARGS__);  \
>   } while (0)
> -#else
> -#define brcmf_err(fmt, ...) \
> - __brcmf_err(__func__, fmt, ##__VA_ARGS__)
> -#endif
>  
>  #if defined(DEBUG) || defined(CONFIG_BRCM_TRACING)
>  __printf(3, 4)
> 

Re: [PATCH net] brcmfmac: clear skb head state on xmit

[Kalle Valo]

Paolo Abeni  writes:

> On Tue, 2017-02-07 at 20:23 +0100, Arend Van Spriel wrote:
>> On 7-2-2017 17:50, Paolo Abeni wrote:
>> > the skbs can be held by the driver for a long time, so we need
>> > to clear any state on xmit to avoid hanging other subsystems.
>> > The skbs are already orphaned later in cmsg code, so we just
>> > need to clear the nf/dst/secpath.
>> > Do it early, while the relevant entries are hopefully still
>> > hot in the cache.
>> 
>> What is this about really? A bit more background about the issue
>> might
>> help understanding the need for this patch. Is this really specific
>> to
>> brcmfmac. For instance is something similar already done in mac80211?
>
> The issue is apparently driver specific, as reported in:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1294415
>
> This is caused by xmit skbs carrying a notrack ct entry not being freed
> by the device driver in a timely manner. Removing the ct module waits
> for such entries refcount going to zero and hangs the kernel in busy
> loop (for several minutes).
>
> The relevant skbs are icmp6 packets (ND if I recall correctly, they
> bcast packets at the mac level).
>
> The only other known device driver suffering for the issue is the
> infiniband ipoib driver, I send a separate patch for it.
>
> I lack the broadcom h/w, but with infiniband the bug can be reproduced
> with the following steps:
>
> - ensure ipv6 is enabled on the target device, and firewalld is running
> (e.g. the module nf_conntrack_ipv6 is loaded)
> - assign a static ip to the device
> - shut down the firewall (e.g. try to remove the module nf_conntrack)
>
> For the brcmfmac driver most probably it is necessary being
> disassociated from the AP before shutting down the firewall (but I
> can't double check). This is probably why mac80211 does not suffer this
> issue.
>
> The root cause for the issue could be actually a firmware issue, any
> better clues are more than welcome!

BTW, you should have added all this to the commit log. After reading the
original description it left more questions open than answered them.

-- 
Kalle Valo

Re: [PATCH net] brcmfmac: clear skb head state on xmit

[Paolo Abeni]

On Wed, 2017-02-08 at 12:27 +0200, Kalle Valo wrote:
> Paolo Abeni  writes:
> 
> > On Tue, 2017-02-07 at 20:23 +0100, Arend Van Spriel wrote:
> > > On 7-2-2017 17:50, Paolo Abeni wrote:
> > > > the skbs can be held by the driver for a long time, so we need
> > > > to clear any state on xmit to avoid hanging other subsystems.
> > > > The skbs are already orphaned later in cmsg code, so we just
> > > > need to clear the nf/dst/secpath.
> > > > Do it early, while the relevant entries are hopefully still
> > > > hot in the cache.
> > > 
> > > What is this about really? A bit more background about the issue
> > > might
> > > help understanding the need for this patch. Is this really specific
> > > to
> > > brcmfmac. For instance is something similar already done in mac80211?
> > 
> > The issue is apparently driver specific, as reported in:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1294415
> > 
> > This is caused by xmit skbs carrying a notrack ct entry not being freed
> > by the device driver in a timely manner. Removing the ct module waits
> > for such entries refcount going to zero and hangs the kernel in busy
> > loop (for several minutes).
> > 
> > The relevant skbs are icmp6 packets (ND if I recall correctly, they
> > bcast packets at the mac level).
> > 
> > The only other known device driver suffering for the issue is the
> > infiniband ipoib driver, I send a separate patch for it.
> > 
> > I lack the broadcom h/w, but with infiniband the bug can be reproduced
> > with the following steps:
> > 
> > - ensure ipv6 is enabled on the target device, and firewalld is running
> > (e.g. the module nf_conntrack_ipv6 is loaded)
> > - assign a static ip to the device
> > - shut down the firewall (e.g. try to remove the module nf_conntrack)
> > 
> > For the brcmfmac driver most probably it is necessary being
> > disassociated from the AP before shutting down the firewall (but I
> > can't double check). This is probably why mac80211 does not suffer this
> > issue.
> > 
> > The root cause for the issue could be actually a firmware issue, any
> > better clues are more than welcome!
> 
> BTW, you should have added all this to the commit log. After reading the
> original description it left more questions open than answered them.

I'm sorry for the lack of clarity, thank you for the advice, will do
next time. 

I tried to keep the commit message short since others reviewer in other
area of the kernel really prefer shorter ones.

Cheers,

Paolo

Re: [PATCH v5 3/3] mt76: add driver code for MT76x2e

[Stanislaw Gruszka]

On Tue, Feb 07, 2017 at 09:20:35PM +0100, Felix Fietkau wrote:
> This is a 2x2 PCIe 802.11ac chipset by MediaTek
> 
> Signed-off-by: Felix Fietkau 
> Signed-off-by: Lorenzo Bianconi 

Reviewed-by: Stanislaw Gruszka 

Re: [PATCH v4 3/5] cfg80211: Accept multiple RSSI thresholds for CQM

[Johannes Berg]

> This method doesn't have a hysteresis parameter because there's no
> benefit to the cfg80211 code from having the hysteresis be handled by
> hardware/driver in terms of the number of wakeups.  At the same time
> it would likely be less consistent between drivers if offloaded or
> done in the drivers.

I'm not really sure I buy this.

What if I configure a few ranges, and let's say one of the boundaries
is -50dBm. Now if I sit just on that value of -50dBm and thus my signal
fluctuates say -48..-52, I'd have to continuously wake up the host.

You try to avoid that here, I think:

+   if (low > (s32) (last - hyst))
+   low = last - hyst;
+   if (high < (s32) (last + hyst))
+   high = last + hyst;

but it's not clear to me that this is effective?

Let's see. last is -52, so low will be -60 and high will be -50.

Let's say hyst is 3 since I chose the ranges so closely. I'm guessing a
higher hysteresis and larger ranges would actually be better, but let's
stick to this for the sake of the example.

last-hyst = -55, so low isn't > that, low = -60
last+hyst = -49, so high = -49

but now it still fluctuates around -50, so if I next hit -48 you do the
same dance again with -50/-40, getting -51/-40 and never really
applying a full hysteresis, no?

I'll probably see an intermediate value of -50 at some point, but I'll
never actually *report* it, so "last" can switch between -48 and -52
constantly in this scenario, no?


I think it would make sense to unconditionally apply the hysteresis to
low/high, i.e. always set
 low = low - hyst
 high = high + hyst

so that you get "sticky" ranges once you're in them?



> + if (!wiphy_ext_feature_isset(>wiphy,
> + 
>    NL80211_EXT_FEATURE_CQM_RSSI_LIST))
> + return
> -EOPNOTSUPP;


That check should be earlier in the function
cfg80211_cqm_rssi_update(), no?



johannes

Re: [PATCH 1/5] nl80211: fix validation of scheduled scan info for wowlan netdetect

[Arend Van Spriel]

On 8-2-2017 10:10, Johannes Berg wrote:
> On Fri, 2017-01-27 at 12:09 +, Arend van Spriel wrote:
>> For wowlan netdetect a separate limit is defined for the number of
>> matchsets. Currently, this limit is ignored and the regular limit
>> for scheduled scan matchsets, ie. struct wiphy::max_match_sets, is
>> used for the net-detect case as well.
> 
> Applied.
> 
> This means that brmcfmac is now broken in mac80211-next for a bit, but
> once it hits net-next and I merge back everything will be fine again,
> so just a few days (and I assume nobody us using brcmfmac from
> mac80211-next anyway ... wireless-testing will be fine)

Well. Almost nobody :-p

Gr. AvS

Re: [PATCH] cfg80211: make rdev assignment clearer in nl80211_testmode_dump()

[Johannes Berg]

On Tue, 2017-02-07 at 22:13 +0200, Luca Coelho wrote:
> From: Luca Coelho 
> 
> Avoid assigning rdev to NULL when we already have it and getting it
> again from the wiphy index, by moving this code to relevant if block.

Applied.

johannes

Re: [PATCH] nl80211: add HT/VHT capabilities to AP parameters

[Johannes Berg]

On Tue, 2017-02-07 at 22:40 +0200, Luca Coelho wrote:
> From: Johannes Berg 
> 
> For the benefit of drivers that rebuild IEs in firmware, parse the
> IEs for HT/VHT capabilities and the respective membership selector
> in the (extended) supported rates. This avoids duplicating the same
> code into all drivers that need this information.
> 

Applied.

johannes

Re: [PATCH v4 2/5] cfg80211: Pass new RSSI level in CQM RSSI notification

[Johannes Berg]

Ok, I've applied patches 1-2 right now, that really makes sense
regardless of the others.

johannes

Re: [PATCH net] brcmfmac: clear skb head state on xmit

[Paolo Abeni]

On Wed, 2017-02-08 at 09:52 +0100, Rafał Miłecki wrote:
> On 8 February 2017 at 09:38, Paolo Abeni  wrote:
> > On Tue, 2017-02-07 at 20:23 +0100, Arend Van Spriel wrote:
> > > On 7-2-2017 17:50, Paolo Abeni wrote:
> > > > the skbs can be held by the driver for a long time, so we need
> > > > to clear any state on xmit to avoid hanging other subsystems.
> > > > The skbs are already orphaned later in cmsg code, so we just
> > > > need to clear the nf/dst/secpath.
> > > > Do it early, while the relevant entries are hopefully still
> > > > hot in the cache.
> > > 
> > > What is this about really? A bit more background about the issue
> > > might
> > > help understanding the need for this patch. Is this really
> > > specific
> > > to
> > > brcmfmac. For instance is something similar already done in
> > > mac80211?
> > 
> > The issue is apparently driver specific, as reported in:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1294415
> > 
> > This is caused by xmit skbs carrying a notrack ct entry not being
> > freed
> > by the device driver in a timely manner. Removing the ct module
> > waits
> > for such entries refcount going to zero and hangs the kernel in
> > busy
> > loop (for several minutes).
> > 
> > The relevant skbs are icmp6 packets (ND if I recall correctly, they
> > bcast packets at the mac level).
> > 
> > The only other known device driver suffering for the issue is the
> > infiniband ipoib driver, I send a separate patch for it.
> > 
> > I lack the broadcom h/w, but with infiniband the bug can be
> > reproduced
> > with the following steps:
> > 
> > - ensure ipv6 is enabled on the target device, and firewalld is
> > running
> > (e.g. the module nf_conntrack_ipv6 is loaded)
> > - assign a static ip to the device
> > - shut down the firewall (e.g. try to remove the module
> > nf_conntrack)
> > 
> > For the brcmfmac driver most probably it is necessary being
> > disassociated from the AP before shutting down the firewall (but I
> > can't double check). This is probably why mac80211 does not suffer
> > this
> > issue.
> > 
> > The root cause for the issue could be actually a firmware issue,
> > any
> > better clues are more than welcome!
> 
> Do I get this correctly brcmfmac gets some skb for transmitting it
> and
> doesn't free it for few minutes? It sounds like some bug that should
> be fixed instead of hiding it.

I mostly agreed, but please also note that early clearing the skb head
state makes sense from a performance pov: we can do the costly,
required, atomic operations while the data is still hot in the cpu L1
cache.

I'm unable to find anything obvious at the driver level, and I think
the root cause could be in the firmware. I hope some more knowledgeable
than me on this topics can have a better look.

Thank you,

Paolo

Re: [PATCH V3 2/9] brcmfmac: switch to C function (__brcmf_err) for printing errors

[Arend Van Spriel]

On 2-2-2017 22:33, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> This will allow extending code and using more detailed messages e.g.
> with the help of dev_err.

Acked-by: Arend van Spriel 
> Signed-off-by: Rafał Miłecki 
> ---
> V3: Keep IS_ENABLED check in the macro as suggested by Felix
> ---
>  .../net/wireless/broadcom/brcm80211/brcmfmac/common.c| 16 
> 
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h |  6 +++---
>  2 files changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> index f7c8c2e80349..33b133f7e63a 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> @@ -218,6 +218,22 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
>   return err;
>  }
>  
> +#ifndef CONFIG_BRCM_TRACING
> +void __brcmf_err(const char *func, const char *fmt, ...)
> +{
> + struct va_format vaf;
> + va_list args;
> +
> + va_start(args, fmt);
> +
> + vaf.fmt = fmt;
> + vaf.va = 
> + pr_err("%s: %pV", func, );
> +
> + va_end(args);
> +}
> +#endif
> +
>  #if defined(CONFIG_BRCM_TRACING) || defined(CONFIG_BRCMDBG)
>  void __brcmf_dbg(u32 level, const char *func, const char *fmt, ...)
>  {
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> index 1fe4aa973a92..441a6661eac0 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> @@ -45,6 +45,8 @@
>  #undef pr_fmt
>  #define pr_fmt(fmt)  KBUILD_MODNAME ": " fmt
>  
> +__printf(2, 3)
> +void __brcmf_err(const char *func, const char *fmt, ...);
>  #ifndef CONFIG_BRCM_TRACING
>  /* Macro for error messages. net_ratelimit() is used when driver
>   * debugging is not selected. When debugging the driver error
> @@ -53,11 +55,9 @@
>  #define brcmf_err(fmt, ...)  \
>   do {\
>   if (IS_ENABLED(CONFIG_BRCMDBG) || net_ratelimit())  \
> - pr_err("%s: " fmt, __func__, ##__VA_ARGS__);\
> + __brcmf_err(__func__, fmt, ##__VA_ARGS__);  \
>   } while (0)
>  #else
> -__printf(2, 3)
> -void __brcmf_err(const char *func, const char *fmt, ...);
>  #define brcmf_err(fmt, ...) \
>   __brcmf_err(__func__, fmt, ##__VA_ARGS__)
>  #endif
> 

Re: [PATCH 1/5] nl80211: fix validation of scheduled scan info for wowlan netdetect

[Johannes Berg]

On Fri, 2017-01-27 at 12:09 +, Arend van Spriel wrote:
> For wowlan netdetect a separate limit is defined for the number of
> matchsets. Currently, this limit is ignored and the regular limit
> for scheduled scan matchsets, ie. struct wiphy::max_match_sets, is
> used for the net-detect case as well.

Applied.

This means that brmcfmac is now broken in mac80211-next for a bit, but
once it hits net-next and I merge back everything will be fine again,
so just a few days (and I assume nobody us using brcmfmac from
mac80211-next anyway ... wireless-testing will be fine)

johannes

Re: [PATCH V3 1/9] brcmfmac: merge two brcmf_err macros into one

[Arend Van Spriel]

On 2-2-2017 22:33, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> This allows simplifying the code by adding a simple IS_ENABLED check for
> CONFIG_BRCMDB symbol.

Acked-by: Arend van Spriel 
> Signed-off-by: Rafał Miłecki 
> ---
> V3: Re-add this patch (it was initially submited as RFC)
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> index 6687812770cc..1fe4aa973a92 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> @@ -45,20 +45,16 @@
>  #undef pr_fmt
>  #define pr_fmt(fmt)  KBUILD_MODNAME ": " fmt
>  
> +#ifndef CONFIG_BRCM_TRACING
>  /* Macro for error messages. net_ratelimit() is used when driver
>   * debugging is not selected. When debugging the driver error
>   * messages are as important as other tracing or even more so.
>   */
> -#ifndef CONFIG_BRCM_TRACING
> -#ifdef CONFIG_BRCMDBG
> -#define brcmf_err(fmt, ...)  pr_err("%s: " fmt, __func__, ##__VA_ARGS__)
> -#else
>  #define brcmf_err(fmt, ...)  \
>   do {\
> - if (net_ratelimit())\
> + if (IS_ENABLED(CONFIG_BRCMDBG) || net_ratelimit())  \
>   pr_err("%s: " fmt, __func__, ##__VA_ARGS__);\
>   } while (0)
> -#endif
>  #else
>  __printf(2, 3)
>  void __brcmf_err(const char *func, const char *fmt, ...);
> 

Re: [patch] mac80211: check for allocation failure in debugfs code

[Johannes Berg]

On Tue, 2017-02-07 at 16:20 +0300, Dan Carpenter wrote:
> kmalloc() can fail.  Also let's move the allocation out of the
> declaration block so it's easier to read.
> 
Applied, thanks.

johannes

Re: [PATCH net] brcmfmac: clear skb head state on xmit

[Rafał Miłecki]

On 8 February 2017 at 09:38, Paolo Abeni  wrote:
> On Tue, 2017-02-07 at 20:23 +0100, Arend Van Spriel wrote:
>> On 7-2-2017 17:50, Paolo Abeni wrote:
>> > the skbs can be held by the driver for a long time, so we need
>> > to clear any state on xmit to avoid hanging other subsystems.
>> > The skbs are already orphaned later in cmsg code, so we just
>> > need to clear the nf/dst/secpath.
>> > Do it early, while the relevant entries are hopefully still
>> > hot in the cache.
>>
>> What is this about really? A bit more background about the issue
>> might
>> help understanding the need for this patch. Is this really specific
>> to
>> brcmfmac. For instance is something similar already done in mac80211?
>
> The issue is apparently driver specific, as reported in:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1294415
>
> This is caused by xmit skbs carrying a notrack ct entry not being freed
> by the device driver in a timely manner. Removing the ct module waits
> for such entries refcount going to zero and hangs the kernel in busy
> loop (for several minutes).
>
> The relevant skbs are icmp6 packets (ND if I recall correctly, they
> bcast packets at the mac level).
>
> The only other known device driver suffering for the issue is the
> infiniband ipoib driver, I send a separate patch for it.
>
> I lack the broadcom h/w, but with infiniband the bug can be reproduced
> with the following steps:
>
> - ensure ipv6 is enabled on the target device, and firewalld is running
> (e.g. the module nf_conntrack_ipv6 is loaded)
> - assign a static ip to the device
> - shut down the firewall (e.g. try to remove the module nf_conntrack)
>
> For the brcmfmac driver most probably it is necessary being
> disassociated from the AP before shutting down the firewall (but I
> can't double check). This is probably why mac80211 does not suffer this
> issue.
>
> The root cause for the issue could be actually a firmware issue, any
> better clues are more than welcome!

Do I get this correctly brcmfmac gets some skb for transmitting it and
doesn't free it for few minutes? It sounds like some bug that should
be fixed instead of hiding it.

-- 
Rafał

Re: [PATCH net] brcmfmac: clear skb head state on xmit

[Paolo Abeni]

On Tue, 2017-02-07 at 20:23 +0100, Arend Van Spriel wrote:
> On 7-2-2017 17:50, Paolo Abeni wrote:
> > the skbs can be held by the driver for a long time, so we need
> > to clear any state on xmit to avoid hanging other subsystems.
> > The skbs are already orphaned later in cmsg code, so we just
> > need to clear the nf/dst/secpath.
> > Do it early, while the relevant entries are hopefully still
> > hot in the cache.
> 
> What is this about really? A bit more background about the issue
> might
> help understanding the need for this patch. Is this really specific
> to
> brcmfmac. For instance is something similar already done in mac80211?

The issue is apparently driver specific, as reported in:

https://bugzilla.redhat.com/show_bug.cgi?id=1294415

This is caused by xmit skbs carrying a notrack ct entry not being freed
by the device driver in a timely manner. Removing the ct module waits
for such entries refcount going to zero and hangs the kernel in busy
loop (for several minutes).

The relevant skbs are icmp6 packets (ND if I recall correctly, they
bcast packets at the mac level).

The only other known device driver suffering for the issue is the
infiniband ipoib driver, I send a separate patch for it.

I lack the broadcom h/w, but with infiniband the bug can be reproduced
with the following steps:

- ensure ipv6 is enabled on the target device, and firewalld is running
(e.g. the module nf_conntrack_ipv6 is loaded)
- assign a static ip to the device
- shut down the firewall (e.g. try to remove the module nf_conntrack)

For the brcmfmac driver most probably it is necessary being
disassociated from the AP before shutting down the firewall (but I
can't double check). This is probably why mac80211 does not suffer this
issue.

The root cause for the issue could be actually a firmware issue, any
better clues are more than welcome!

Thank you,

Paolo

Re: [PATCH v2 2/3] mac80211: Make mesh failure moving average configurable

[Johannes Berg]

On Tue, 2017-01-31 at 12:07 -0800, Rajkumar Manoharan wrote:
> Currently mesh moving fail average is calculated based on constant
> weight factor. In worst case moving average reaches threshold by
> considering 16 msdu tx ack status and deactivates mesh path. Having
> a constant weight factor might not be suitable for all environments.
> So make it tunable parameter and also lower default weight to 10 so
> that mesh broken link calculation will consider more packet status
> (32 msdus ack status) before dropping mesh path.

I don't think this makes a lot of sense, and with a conversion to the
EWMA helpers it would probably not really be possible anyway.

johannes

Re: [PATCH v2 1/3] mac80211: fix mesh moving average stuck

[Johannes Berg]

On Tue, 2017-01-31 at 12:07 -0800, Rajkumar Manoharan wrote:
> As moving average is not considering fractional part after
> certain ratio, it will stuck at the same state. For example
> with current values, moving average stuck at 96 and it will
> not move forward. Fortunately current threshold is matching
> against 95%. If thresold is increased more than 96, mesh path
> never be deactivated under worst case. Fix failure average
> movement by bumping up average at stuck state.

This is ... really strange to me.

Can't we just actually take into account fractional parts instead?

I think you should instead convert this to the EMWA helpers (see
include/linux/average.h).

johannes

RE: [PATCH v9] Add new mac80211 driver mwlwifi.

[David Lin]

> From: Rafał Miłecki [mailto:zaj...@gmail.com] worte: 
> On 8 February 2017 at 08:28, David Lin  wrote:
> >> From: Rafał Miłecki [mailto:zaj...@gmail.com] worte:
> >> Sent: Wednesday, February 08, 2017 3:24 PM On 8 February 2017 at
> >> 07:30, David Lin  wrote:
> >> > steve.deros...@gmail.com [mailto:steve.deros...@gmail.com] wrote:
> >> >> On Tue, Feb 7, 2017 at 10:15 PM, David Lin  wrote:
> >> >> >> Rafał Miłecki [mailto:zaj...@gmail.com] wrote:
> >> >> >> Please use ieee80211-freq-limit:
> >> >> >> https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git
> >> >> >> /co
> >> >> >> mmi
> >> >> >> t/?id=b3
> >> >> >> 30b25eaabda00d74e47566d9200907da381896
> >> >> >>
> >> >> >> Most likely with wiphy_read_of_freq_limits helper:
> >> >> >> https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git
> >> >> >> /co
> >> >> >> mmi
> >> >> >> t/?id=e6
> >> >> >> 91ac2f75b69bee743f0370d79454ba4429b175
> >> >> >
> >> >> > I already replied meaning of these parameters:
> >> >> >  is used to disable 2g band.
> >> >> >  is used to disable 5g band.
> >> >> >  is used to specify antenna number (if
> >> >> > default number
> >> >> is suitable for you, there is no need to use this parameter).
> >> >> >  should not be used for chip with device
> >> >> > power
> >> table.
> >> >> In fact, this parameter should not be used any more.
> >> >> >
> >> >>
> >> >> David, I think you're not understanding the comment, or at least
> >> >> that's what it looks like to me. Yes, you did reply as to the meaning.
> >> >> And, your reply, while informative, didn't tell us you understood
> >> >> and were willing to fix the problem. I doubt you meant it this
> >> >> way, but it feels defensive and like a brush-off.
> >> >>
> >> >> First off, you will still have to document any DT bindings you're
> >> >> adding. Just because you answer the question in the review doesn't
> >> >> mean you're not responsible for doing so.
> >> >>
> >> >> And second off, I think that Rafal (and sorry about my spelling,
> >> >> looks like there's some sort of accent on the l that I don't know
> >> >> how to make my keyboard do) is saying: there's already some
> >> >> generic bindings that can be used to disable the 2g or 5g bands.
> >> >> Granted they're even newer than your patch, but I do think if said
> >> >> bindings exist and
> >> are appropriate, you should use them.
> >> >>
> >> >> - Steve
> >> >
> >> > These parameters are marvell proprietary parameters, I don't think
> >> > it should
> >> be added to DT bindings.
> >>
> >> Steve is correct.
> >>
> >> You have to document new properties, just because they are Marvell
> >> specific doesn't change anything. You just document them in a proper
> place.
> >>
> >
> > All right. I will do that.
> >
> >>
> >> > BTW,  and  are only used for mwlwifi to
> >> > report
> >> supported bands, it is not related to limitation of frequency.
> >>
> >> How reporting a single band doesn't limit reported frequencies? You
> >> can achieve exactly the same using generic property, so there is no
> >> place for Marvell specific ones.
> >>
> >> In fact there were drivers of 3 vendors requiring band/freq-related
> >> description in DT: Broadcom, Marvell & Mediatek. This property was
> >> discussed & designed to support all limitation cases we found
> >> possible to make it usable with
> >> (hopefully) all drivers.
> >>
> >
> > I only need simple way to disable 2g or 5g band. I will follow your 
> > suggestion
> to document these marvell proprietary parameters.
> 
> Seriously? Refusing to use generic binding because you think marvell,5ghz; is
> simpler than ieee80211-freq-limit = <2402000 2482000>; (not to mention your
> property seems reversed!)?
> 
> I don't know how else to explain this to you. We don't want duplicated
> properties where one can work. Just use existing one. Don't add new one even
> if documented.
> 

All right. I will check and let patch v10 to use it. For previous parameters, 
they will only be used by previous OpenWrt projects.

Thanks,
David

> --
> Rafał

Re: [PATCH] mac80211: Remove VHT Capabilities/Operation IEs from mesh beacon if VHT was disabled

[Johannes Berg]

> This patch removes VHT Capabilities/Operation IEs when the
> wpa_supplicant.conf includes disable_vht=1. We recognize the local
> peer
> as 11ac ready, when it has more than 80MHz band width. Because
> net/mac80211/util.c#ieee80211_build_preq_ies_band() uses 80MHz
> threshold
> for VHT Capabilities IE inclusion.

I believe this is incorrect the way you've written it, we shouldn't
disable VHT because 80 MHz isn't *used* right now.

The code you reference checks if 80 MHz was technically *supported*,
and that's really only because we otherwise can't connect to a BSS
network that supports VHT, since the AP might switch from 20/40 to
80/160, and we can't say that we don't support 80 (since we have to
support it if we support VHT.)

>   sband = local->hw.wiphy->bands[band];
>   if (!sband->vht_cap.vht_supported ||
> - sdata->vif.bss_conf.chandef.width ==
> NL80211_CHAN_WIDTH_20_NOHT ||
> - sdata->vif.bss_conf.chandef.width ==
> NL80211_CHAN_WIDTH_5 ||
> - sdata->vif.bss_conf.chandef.width ==
> NL80211_CHAN_WIDTH_10)
> + !(sdata->vif.bss_conf.chandef.width ==
> NL80211_CHAN_WIDTH_80 ||
> + sdata->vif.bss_conf.chandef.width ==
> NL80211_CHAN_WIDTH_80P80 ||
> + sdata->vif.bss_conf.chandef.width ==
> NL80211_CHAN_WIDTH_160))
>   return 0;
> 

But using the current bandwidth as you do now seems incorrect to me.

johannes

Re: [PATCH v3 0/2] mac80211: use crypto shash for AES cmac

[Johannes Berg]

Both applied, thanks.

johannes

Re: [PATCH] Print text for disassociation reason.

[Johannes Berg]

> Don't know why it wasn't printed there with
> ieee80211_get_reason_code_string in first
> place. Works for me:
> 
> kernel: wlan0: disassociated from 04:b0:20:33:ff:1f (Reason:
> 34=DISASSOC_LOW_ACK)

This patch needs a "mac80211: " prefix, and I'd prefer no . at the end
(but that's not a hard rule)

> ps. can't send patch in normal way due to postmaster@vger weirdness,
> so inserted
> below
> 
> From c9b55bb44fe0b902f376a41fa930c9a67a438511 Mon Sep 17 00:00:00
> 2001
> From: =?UTF-8?q?Arkadiusz=20Mi=C5=9Bkiewicz?= 
> Date: Mon, 6 Feb 2017 14:45:15 +0100
> Subject: [PATCH] Print text for disassociation reason.
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> When disassociation happens only numeric reason is printed
> in ieee80211_rx_mgmt_disassoc(). Add text variant, too.
> 
> Signed-off-by: Arkadiusz Miśkiewicz 

This is useless to me, please resubmit without all the fluff. You can
insert a "From: " line into the first line of the email *body* to get
the author correct, if you can't actually send it from the correct
email address. git send-email will even do that for you.

johannes