linux.git/drivers/net/wireless, branch v4.20-rc4

mt76: fix uninitialized mutex access setting rts threshold

2018-11-16T13:15:49+00:00

Fix following crash due to a leftover uninitialized mutex access
in mt76x2_set_rts_threshold routine.

[   31.018059] Call Trace:
[   31.018341]  register_lock_class+0x51f/0x530
[   31.018828]  __lock_acquire+0x6c/0x1580
[   31.019247]  lock_acquire+0x88/0x120
[   31.021089]  __mutex_lock+0x4a/0x4f0
[   31.023343]  mt76x2_set_rts_threshold+0x28/0x50
[   31.023831]  ieee80211_set_wiphy_params+0x16d/0x4e0
[   31.024344]  nl80211_set_wiphy+0x72b/0xbc0
[   31.024781]  genl_family_rcv_msg+0x192/0x3a0
[   31.025233]  genl_rcv_msg+0x42/0x89
[   31.026079]  netlink_rcv_skb+0x38/0x100
[   31.026475]  genl_rcv+0x1f/0x30
[   31.026804]  netlink_unicast+0x19c/0x250
[   31.027212]  netlink_sendmsg+0x1ed/0x390
[   31.027615]  sock_sendmsg+0x31/0x40
[   31.027973]  ___sys_sendmsg+0x23c/0x280
[   31.030414]  __sys_sendmsg+0x42/0x80
[   31.030783]  do_syscall_64+0x4a/0x170
[   31.031160]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[   31.031677] RIP: 0033:0x7f3498b39ba7
[   31.033953] RSP: 002b:00007fffe19675b8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
[   31.034883] RAX: ffffffffffffffda RBX: 00000000012d5350 RCX: 00007f3498b39ba7
[   31.035756] RDX: 0000000000000000 RSI: 00007fffe19675f0 RDI: 0000000000000003
[   31.036587] RBP: 00000000012da740 R08: 0000000000000002 R09: 0000000000000000
[   31.037422] R10: 0000000000000006 R11: 0000000000000246 R12: 00000000012da880
[   31.038252] R13: 00007fffe19675f0 R14: 00007fffe19678c0 R15: 00000000012da880

Fixes: 108a4861ef19 ("mt76: create new mt76x02-lib module for common mt76x{0,2} code")
Reported-by: lorenzo.trisolini@fluidmesh.com
Reported-by: luca.bisti@fluidmesh.com
Signed-off-by: Lorenzo Bianconi 
Signed-off-by: Kalle Valo

brcmfmac: fix reporting support for 160 MHz channels

2018-11-16T13:10:18+00:00

Driver can report IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ so it's
important to provide valid & complete info about supported bands for
each channel. By default no support for 160 MHz should be assumed unless
firmware reports it for a given channel later.

This fixes info passed to the userspace. Without that change userspace
could try to use invalid channel and fail to start an interface.

Signed-off-by: Rafał Miłecki 
Cc: stable@vger.kernel.org
Signed-off-by: Kalle Valo

ath10k: don't assume 'vif' is non-NULL in flush()

2018-11-16T13:07:42+00:00

mac80211 may call us with vif == NULL, if the station is not currently
active (e.g., not associated). It is trivially easy to reproduce a crash
by suspending the system when not connected to an AP:

[   65.533934] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
...
[   65.574521] pc : ath10k_flush+0x30/0xd0 [ath10k_core]
[   65.574538] lr : __ieee80211_flush_queues+0x180/0x244 [mac80211]
[   65.599680] Process kworker/u12:1 (pid: 57, stack limit = 0x(____ptrval____))
[   65.599682] Call trace:
[   65.599695]  ath10k_flush+0x30/0xd0 [ath10k_core]
[   65.642064]  __ieee80211_flush_queues+0x180/0x244 [mac80211]
[   65.642079]  ieee80211_flush_queues+0x34/0x40 [mac80211]
[   65.642095]  __ieee80211_suspend+0xfc/0x47c [mac80211]
[   65.658611]  ieee80211_suspend+0x30/0x3c [mac80211]
[   65.658627]  wiphy_suspend+0x15c/0x3a8 [cfg80211]
[   65.672810]  dpm_run_callback+0xf0/0x1f0
[   65.672814]  __device_suspend+0x3ac/0x4f8
[   65.672819]  async_suspend+0x34/0xbc
[   65.684096]  async_run_entry_fn+0x54/0x104
[   65.684099]  worker_thread+0x4cc/0x72c
[   65.684102]  kthread+0x134/0x13c
[   65.684105]  ret_from_fork+0x10/0x18

Fixes: 9de4162f0999 ("ath10k: add peer flush in ath10k_flush for STATION")
Signed-off-by: Brian Norris 
Signed-off-by: Kalle Valo

iwlwifi: mvm: don't use SAR Geo if basic SAR is not used

2018-11-15T21:50:59+00:00

We can't use SAR Geo if basic SAR is not enabled, since the SAR Geo
tables define offsets in relation to the basic SAR table in use.

To fix this, make iwl_mvm_sar_init() return one in case WRDS is not
available, so we can skip reading WGDS entirely.

Fixes: a6bff3cb19b7 ("iwlwifi: mvm: add GEO_TX_POWER_LIMIT cmd for geographic tx power table")
Cc: stable@vger.kernel.org # 4.12+
Signed-off-by: Luca Coelho

iwlwifi: fix D3 debug data buffer memory leak

2018-11-15T21:50:59+00:00

If the driver is unloaded when D3 debug data pulling is enabled
but not triggered, it doesn't release the data buffer.

Fix this by adding iwl_fw_runtime_free and calling it from the
relevant places.

Fixes: 2d8c261511ab ("iwlwifi: add d3 debug data support")
Signed-off-by: Shahar S Matityahu 
Signed-off-by: Luca Coelho

iwlwifi: mvm: fix regulatory domain update when the firmware starts

2018-11-15T21:50:58+00:00

When the firmware starts, it doesn't have any regulatory
information, hence it uses the world wide limitations. The
driver can feed the firmware with previous knowledge that
was kept in the driver, but the firmware may still not
update its internal tables.

This happens when we start a BSS interface, and then the
firmware can change the regulatory tables based on our
location and it'll use more lenient, location specific
rules. Then, if the firmware is shut down (when the
interface is brought down), and then an AP interface is
created, the firmware will forget the country specific
rules.

The host will think that we are in a certain country that
may allow channels and will try to teach the firmware about
our location, but the firmware may still not allow to drop
the world wide limitations and apply country specific rules
because it was just re-started.

In this case, the firmware will reply with MCC_RESP_ILLEGAL
to the MCC_UPDATE_CMD. In that case, iwlwifi needs to let
the upper layers (cfg80211 / hostapd) know that the channel
list they know about has been updated.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201105

Cc: stable@vger.kernel.org
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho

iwlwifi: mvm: support sta_statistics() even on older firmware

2018-11-15T21:50:58+00:00

The oldest firmware supported by iwlmvm do support getting
the average beacon RSSI. Enable the sta_statistics() call
from mac80211 even on older firmware versions.

Fixes: 33cef9256342 ("iwlwifi: mvm: support beacon statistics for BSS client")
Cc: stable@vger.kernel.org # 4.2+
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho

iwlwifi: fix wrong WGDS_WIFI_DATA_SIZE

2018-11-15T21:50:58+00:00

From coreboot/BIOS:
Name ("WGDS", Package() {
 Revision,
 Package() {
     DomainType,                         // 0x7:WiFi ==> We miss this one.
     WgdsWiFiSarDeltaGroup1PowerMax1,    // Group 1 FCC 2400 Max
     WgdsWiFiSarDeltaGroup1PowerChainA1, // Group 1 FCC 2400 A Offset
     WgdsWiFiSarDeltaGroup1PowerChainB1, // Group 1 FCC 2400 B Offset
     WgdsWiFiSarDeltaGroup1PowerMax2,    // Group 1 FCC 5200 Max
     WgdsWiFiSarDeltaGroup1PowerChainA2, // Group 1 FCC 5200 A Offset
     WgdsWiFiSarDeltaGroup1PowerChainB2, // Group 1 FCC 5200 B Offset
     WgdsWiFiSarDeltaGroup2PowerMax1,    // Group 2 EC Jap 2400 Max
     WgdsWiFiSarDeltaGroup2PowerChainA1, // Group 2 EC Jap 2400 A Offset
     WgdsWiFiSarDeltaGroup2PowerChainB1, // Group 2 EC Jap 2400 B Offset
     WgdsWiFiSarDeltaGroup2PowerMax2,    // Group 2 EC Jap 5200 Max
     WgdsWiFiSarDeltaGroup2PowerChainA2, // Group 2 EC Jap 5200 A Offset
     WgdsWiFiSarDeltaGroup2PowerChainB2, // Group 2 EC Jap 5200 B Offset
     WgdsWiFiSarDeltaGroup3PowerMax1,    // Group 3 ROW 2400 Max
     WgdsWiFiSarDeltaGroup3PowerChainA1, // Group 3 ROW 2400 A Offset
     WgdsWiFiSarDeltaGroup3PowerChainB1, // Group 3 ROW 2400 B Offset
     WgdsWiFiSarDeltaGroup3PowerMax2,    // Group 3 ROW 5200 Max
     WgdsWiFiSarDeltaGroup3PowerChainA2, // Group 3 ROW 5200 A Offset
     WgdsWiFiSarDeltaGroup3PowerChainB2, // Group 3 ROW 5200 B Offset
 }
})

When read the ACPI data to find out the WGDS, the DATA_SIZE is never
matched.
From the above format, it gives 19 numbers, but our driver is hardcode
as 18.
Fix it to pass then can parse the data into our wgds table.
Then we will see:
iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init Sending GEO_TX_POWER_LIMIT
iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[0]
Band[0]: chain A = 68 chain B = 69 max_tx_power = 54
iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[0]
Band[1]: chain A = 48 chain B = 49 max_tx_power = 70
iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[1]
Band[0]: chain A = 51 chain B = 67 max_tx_power = 50
iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[1]
Band[1]: chain A = 69 chain B = 70 max_tx_power = 68
iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[2]
Band[0]: chain A = 49 chain B = 50 max_tx_power = 48
iwlwifi 0000:01:00.0: U iwl_mvm_sar_geo_init SAR geographic profile[2]
Band[1]: chain A = 52 chain B = 53 max_tx_power = 51

Cc: stable@vger.kernel.org # 4.12+
Fixes: a6bff3cb19b7 ("iwlwifi: mvm: add GEO_TX_POWER_LIMIT cmd for geographic tx power table")
Signed-off-by: Matt Chen 
Signed-off-by: Luca Coelho

mt76: fix building without CONFIG_LEDS_CLASS

2018-11-06T16:46:33+00:00

When CONFIG_LEDS_CLASS is disabled, or it is a loadable module while
mt76 is built-in, we run into a link error:

drivers/net/wireless/mediatek/mt76/mac80211.o: In function `mt76_register_device':
mac80211.c:(.text+0xb78): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `devm_of_led_classdev_register'

We don't really need a hard dependency here as the driver can presumably
work just fine without LEDs, so this follows the iwlwifi example and
adds a separate Kconfig option for the LED support, this will be available
whenever it will link, and otherwise the respective code gets left out from
the driver object.

Fixes: 17f1de56df05 ("mt76: add common code shared between multiple chipsets")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Lorenzo Bianconi 
Signed-off-by: Kalle Valo

brcmutil: really fix decoding channel info for 160 MHz bandwidth

2018-11-06T16:46:00+00:00

Previous commit /adding/ support for 160 MHz chanspecs was incomplete.
It didn't set bandwidth info and didn't extract control channel info. As
the result it was also using uninitialized "sb" var.

This change has been tested for two chanspecs found to be reported by
some devices/firmwares:
1) 60/160 (0xee32)
   Before: chnum:50 control_ch_num:36
    After: chnum:50 control_ch_num:60
2) 120/160 (0xed72)
   Before: chnum:114 control_ch_num:100
    After: chnum:114 control_ch_num:120

Fixes: 330994e8e8ec ("brcmfmac: fix for proper support of 160MHz bandwidth")
Signed-off-by: Rafał Miłecki 
Signed-off-by: Kalle Valo