kernel/linux.git/net/mac80211/vht.c, branch linux-4.16.y

mac80211: fix bandwidth computation for TDLS peers

2017-10-02T12:06:19+00:00

Section 11.23.1 of 80211-2016 specification allows TDLS peers to operate on wider bandwidths though they are connected to a BSS which do not support wider bandwidth operations, provided both the peers advertise wider bandwidth capabilities. The existing logic considers the minimum of station's and AP's capability for bandwidth computation. The same logic applies for TDLS peers as well, this restricts operating on wider bandwidths over a TDLS link when the peers are connected to legacy APs. As an example, if 80Mhz VHT capable peers are connected to a 20Mhz 5 GHz AP, then as per the existing logic TDLS operation will be restricted to 20Mhz. Address this problem by not considering BSS capability in bandwidth computation if the participating TDLS peers have wider bandwidth capability. Signed-off-by: Manikanta Pubbisetty [lots of wording/typo fixes] Signed-off-by: Johannes Berg

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2017-01-17T20:19:37+00:00

mac80211: recalculate min channel width on VHT opmode changes

2017-01-11T15:35:05+00:00

When an associated station changes its VHT operating mode this can/will affect the bandwidth it's using, and consequently we must recalculate the minimum bandwidth we need to use. Failure to do so can lead to one of two scenarios: 1) we use a too high bandwidth, this is benign 2) we use a too narrow bandwidth, causing rate control and actual PHY configuration to be out of sync, which can in turn cause problems/crashes Signed-off-by: Johannes Berg

mac80211: Remove unused 'sband' and 'local' variables

2016-12-13T15:05:09+00:00

Commit b1bce14a7954 (mac80211: update opmode when adding new station) refactored ieee80211_vht_handle_opmode into __ieee80211_vht_handle_opmode and ieee80211_vht_handle_opmode leaving a set but unused variable (sband) in the former. Compiling with W=1 gives the following warning, fix it. net/mac80211/vht.c: In function ‘__ieee80211_vht_handle_opmode’: net/mac80211/vht.c:424:35: warning: variable ‘sband’ set but not used [-Wunused-but-set-variable] Remove 'struct ieee80211_local* local' as well, it was only used to set sband. This is a harmless warning, and is only being fixed to reduce the noise with W=1 in the kernel. Fixes: b1bce14a7954 ("mac80211: update opmode when adding new station") Cc: Marek Kwaczynski Cc: Johannes Berg Signed-off-by: Kirtika Ruchandani Signed-off-by: Johannes Berg

mac80211: Ignore VHT IE from peer with wrong rx_mcs_map

2016-11-15T13:18:43+00:00

This is a workaround for VHT-enabled STAs which break the spec and have the VHT-MCS Rx map filled in with value 3 for all eight spacial streams, an example is AR9462 in AP mode. As per spec, in section 22.1.1 Introduction to the VHT PHY A VHT STA shall support at least single spactial stream VHT-MCSs 0 to 7 (transmit and receive) in all supported channel widths. Some devices in STA mode will get firmware assert when trying to associate, examples are QCA9377 & QCA6174. Packet example of broken VHT Cap IE of AR9462: Tag: VHT Capabilities (IEEE Std 802.11ac/D3.1) Tag Number: VHT Capabilities (IEEE Std 802.11ac/D3.1) (191) Tag length: 12 VHT Capabilities Info: 0x00000000 VHT Supported MCS Set Rx MCS Map: 0xffff .... .... .... ..11 = Rx 1 SS: Not Supported (0x0003) .... .... .... 11.. = Rx 2 SS: Not Supported (0x0003) .... .... ..11 .... = Rx 3 SS: Not Supported (0x0003) .... .... 11.. .... = Rx 4 SS: Not Supported (0x0003) .... ..11 .... .... = Rx 5 SS: Not Supported (0x0003) .... 11.. .... .... = Rx 6 SS: Not Supported (0x0003) ..11 .... .... .... = Rx 7 SS: Not Supported (0x0003) 11.. .... .... .... = Rx 8 SS: Not Supported (0x0003) ...0 0000 0000 0000 = Rx Highest Long GI Data Rate (in Mb/s, 0 = subfield not in use): 0x0000 Tx MCS Map: 0xffff ...0 0000 0000 0000 = Tx Highest Long GI Data Rate (in Mb/s, 0 = subfield not in use): 0x0000 Signed-off-by: Filip Matusiak Signed-off-by: Johannes Berg

cfg80211: remove enum ieee80211_band

2016-04-12T13:56:15+00:00

This enum is already perfectly aliased to enum nl80211_band, and the only reason for it is that we get IEEE80211_NUM_BANDS out of it. There's no really good reason to not declare the number of bands in nl80211 though, so do that and remove the cfg80211 one. Signed-off-by: Johannes Berg

mac80211: TDLS: change BW calculation for WIDER_BW peers

2016-04-05T08:50:52+00:00

The previous approach simply ignored chandef restrictions when calculating the appropriate peer BW for a WIDER_BW peer. This could result in a regulatory violation if both peers indicated 80MHz support, but the regdomain forbade it. Change the approach to setting a WIDER_BW peer's BW. Don't exempt it from the chandef width at first. If during TDLS negotiation the chandef width is upgraded, update the peer's BW to match. Fixes: 0fabfaafec3a ("mac80211: upgrade BW of TDLS peers when possible") Signed-off-by: Arik Nemtsov Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg

mac80211: move MU_MIMO_OWNER flag to ieee80211_vif

2016-02-24T08:04:40+00:00

Drivers may need to track which vif is using VHT MU-MIMO. Move the flag indicationg the ownership of MU_MIMO to ieee80211_vif. Signed-off-by: Sara Sharon Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg

mac80211: provide interface to driver to set VHT MU-MIMO data

2016-02-24T08:04:40+00:00

Provide an interface to the lower level driver to set the VHT MU-MIMO data. This is needed for example when there is an update of the group data during low power state, where the management frame will not be passed to the host at all. Signed-off-by: Sara Sharon Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg

mac80211: fix VHT MU-MIMO frame processing

2016-02-24T08:04:36+00:00

The source and destintation addresses in the memcpy arguments are flipped. Fix that. Fixes: 23a1f8d44c0b("mac80211: process and save VHT MU-MIMO group frame") Signed-off-by: Sara Sharon Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg