diff mbox

[LEDE-DEV,v2] mac80211: backport calculate-min-channel-width fix

Message ID 1484912433-2253-1-git-send-email-koen.vandeputte@ncentric.com
State Changes Requested
Headers show

Commit Message

Koen Vandeputte Jan. 20, 2017, 11:40 a.m. UTC 
compiled & tested on cns3xxx

Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
---
 ...211-calculate-min-channel-width-correctly.patch | 53 ++++++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 package/kernel/mac80211/patches/354-mac80211-calculate-min-channel-width-correctly.patch

Comments

Felix Fietkau Jan. 25, 2017, 8:29 a.m. UTC | #1 
On 2017-01-20 12:40, Koen Vandeputte wrote:
> compiled & tested on cns3xxx
> 
> Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
This commit introduces a regression and needs the fixup "mac80211: don't
try to sleep in rate_control_rate_init()" as well.

- Felix
Koen Vandeputte Jan. 27, 2017, 11:54 a.m. UTC | #2 
On 2017-01-25 09:29, Felix Fietkau wrote:
> On 2017-01-20 12:40, Koen Vandeputte wrote:
>> compiled & tested on cns3xxx
>>
>> Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
> This commit introduces a regression and needs the fixup "mac80211: don't
> try to sleep in rate_control_rate_init()" as well.
Please drop it as it will be superseded soon by commit --> "mac80211: 
update to wireless-testing 2017-01-25"

> - Felix
diff mbox

Patch

diff --git a/package/kernel/mac80211/patches/354-mac80211-calculate-min-channel-width-correctly.patch b/package/kernel/mac80211/patches/354-mac80211-calculate-min-channel-width-correctly.patch
new file mode 100644
index 0000000..4567b02
--- /dev/null
+++ b/package/kernel/mac80211/patches/354-mac80211-calculate-min-channel-width-correctly.patch
@@ -0,0 +1,53 @@ 
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Fri, 7 Oct 2016 12:23:49 +0200
+Subject: [PATCH] mac80211: calculate min channel width correctly
+
+In the current minimum chandef code there's an issue in that the
+recalculation can happen after rate control is initialized for a
+station that has a wider bandwidth than the current chanctx, and
+then rate control can immediately start using those higher rates
+which could cause problems.
+
+Observe that first of all that this problem is because we don't
+take non-associated and non-uploaded stations into account. The
+restriction to non-associated is quite pointless and is one of
+the causes for the problem described above, since the rate init
+will happen before the station is set to associated; no frames
+could actually be sent until associated, but the rate table can
+already contain higher rates and that might cause problems.
+
+Also, rejecting non-uploaded stations is wrong, since the rate
+control can select higher rates for those as well.
+
+Secondly, it's then necessary to recalculate the minimal config
+before initializing rate control, so that when rate control is
+initialized, the higher rates are already available. This can be
+done easily by adding the necessary function call in rate init.
+
+Change-Id: Ib9bc02d34797078db55459d196993f39dcd43070
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+---
+
+--- a/net/mac80211/chan.c
++++ b/net/mac80211/chan.c
+@@ -231,9 +231,6 @@ ieee80211_get_max_required_bw(struct iee
+ 		    !(sta->sdata->bss && sta->sdata->bss == sdata->bss))
+ 			continue;
+ 
+-		if (!sta->uploaded || !test_sta_flag(sta, WLAN_STA_ASSOC))
+-			continue;
+-
+ 		max_bw = max(max_bw, ieee80211_get_sta_bw(&sta->sta));
+ 	}
+ 	rcu_read_unlock();
+--- a/net/mac80211/rate.c
++++ b/net/mac80211/rate.c
+@@ -40,6 +40,8 @@ void rate_control_rate_init(struct sta_i
+ 
+ 	ieee80211_sta_set_rx_nss(sta);
+ 
++	ieee80211_recalc_min_chandef(sta->sdata);
++
+ 	if (!ref)
+ 		return;
+