Re: pull-request: mac80211 2015-11-26

2015-12-02 Thread David Miller
From: Johannes Berg 
Date: Wed, 02 Dec 2015 10:46:50 +0100

>> 
>> A small set of fixes for 4.4:
>>  * remove NL80211_FEATURE_FULL_AP_CLIENT_STATE again, it
>>    was broken and needs more work, we'll enable it for 4.5
>>  * fix call_rcu() induced use-after-reset/free in mesh
>>    (that was suddenly causing issues in certain tests)
>>  * always request block-ack window size 64 as we found
>>    some APs will otherwise crash (really ...)
>>  * fix P2P-Device teardown sequence to avoid restarting
>>    with uninitialized data
> 
> I've got two more fairly important changes - one for regulatory issues
> and one for an uninitialized variable that was leading to fairly
> obscure bugs - do you prefer I wait, or send a new pull request
> covering this one plus the two new fixes?

Please add them and send a new pull request, I'll just skip over your
existing one.

THanks.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: pull-request: mac80211 2015-11-26

2015-12-02 Thread Johannes Berg
Hi,

> 
> A small set of fixes for 4.4:
>  * remove NL80211_FEATURE_FULL_AP_CLIENT_STATE again, it
>    was broken and needs more work, we'll enable it for 4.5
>  * fix call_rcu() induced use-after-reset/free in mesh
>    (that was suddenly causing issues in certain tests)
>  * always request block-ack window size 64 as we found
>    some APs will otherwise crash (really ...)
>  * fix P2P-Device teardown sequence to avoid restarting
>    with uninitialized data

I've got two more fairly important changes - one for regulatory issues
and one for an uninitialized variable that was leading to fairly
obscure bugs - do you prefer I wait, or send a new pull request
covering this one plus the two new fixes?

Thanks,
johannes
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


pull-request: mac80211 2015-11-26

2015-11-26 Thread Johannes Berg
[resending with correct netdev address, not sure how that ended up in
my autocompletion address book ... sorry about that!]

Hi Dave,

Sorry for being so late. These have been pending for a while (and in
fact in linux-next too, I asked to be added there recently :) ).

Let me know if there's any problem.

Thanks,
johannes


The following changes since commit
17c790a60dad11c0193127e83ac8e183b4fed1a2:

  Merge branch 'mv88e6060-fixes' (2015-11-15 20:16:26 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git
tags/mac80211-for-davem-2015-11-26

for you to fetch changes up to
5ff3ca2888940533dcd50212cf0be7049fee979c:

  mac80211: don't teardown sdata on sdata stop (2015-11-20 11:40:50
+0100)


A small set of fixes for 4.4:
 * remove NL80211_FEATURE_FULL_AP_CLIENT_STATE again, it
   was broken and needs more work, we'll enable it for 4.5
 * fix call_rcu() induced use-after-reset/free in mesh
   (that was suddenly causing issues in certain tests)
 * always request block-ack window size 64 as we found
   some APs will otherwise crash (really ...)
 * fix P2P-Device teardown sequence to avoid restarting
   with uninitialized data


Eliad Peller (1):
  mac80211: don't teardown sdata on sdata stop

Emmanuel Grumbach (1):
  mac80211: ensure we don't update tx power on a non-running sdata

Gregory Greenman (1):
  mac80211: always set the buf_size in AddBA req to 64

Johannes Berg (2):
  mac80211: don't advertise NL80211_FEATURE_FULL_AP_CLIENT_STATE
  mac80211: mesh: fix call_rcu() usage

 include/net/mac80211.h  | 6 --
 net/mac80211/agg-tx.c   | 3 ++-
 net/mac80211/iface.c| 5 +++--
 net/mac80211/main.c | 3 +--
 net/mac80211/mesh_pathtbl.c | 8 
 5 files changed, 14 insertions(+), 11 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html