linux/drivers/net/wireless, branch v5.0

mac80211_hwsim: propagate genlmsg_reply return code

2019-02-22T12:27:22Z

genlmsg_reply can fail, so propagate its return code Signed-off-by: Li RongQing Signed-off-by: Johannes Berg

Merge tag 'wireless-drivers-for-davem-2019-02-18' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers

2019-02-19T01:40:47Z

Kalle Valo says: ==================== wireless-drivers fixes for 5.0 Hopefully the last set of fixes for 5.0, only fix this time. mt76 * fix regression with resume on mt76x0u USB devices ==================== Signed-off-by: David S. Miller

mt76x0u: fix suspend/resume

2019-02-07T16:32:16Z

We need to reset MCU and do other initializations on resume otherwise MT7610U device will fail to initialize, what cause system hung due to USB requests timeouts. Patch fixes 4.19 -> 4.20 regression. Cc: stable@vger.kernel.org # 4.20+ Signed-off-by: Stanislaw Gruszka Acked-by: Lorenzo Bianconi Signed-off-by: Kalle Valo

Merge tag 'wireless-drivers-for-davem-2019-02-04' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers

2019-02-04T17:12:06Z

Kalle Valo says: ==================== wireless-drivers fixes for 5.0 First set of small, but importnat, fixes for 5.0. iwlwifi * fix a build regression introduced in 5.0-rc1 wlcore * fix a firmware regression from v4.18-rc1 mt76x0 * fix for configuring tx power from user space ath10k * fix wcn3990 regression from v4.20-rc1 ==================== Signed-off-by: David S. Miller

ath10k: correct bus type for WCN3990

2019-01-31T16:56:50Z

WCN3990 is SNOC, not PCI. This prevents probing WCN3990. Fixes: 367c899f622c ("ath10k: add bus type check in ath10k_init_hw_params") Signed-off-by: Brian Norris Reviewed-by: Bjorn Andersson Signed-off-by: Kalle Valo

mt76x0: eeprom: fix chan_vs_power map in mt76x0_get_power_info

2019-01-31T16:56:11Z

Report correct eeprom per channel power value. Fix chan_vs_power map in mt76x0_get_power_info routine Fixes: f2a2e819d672 ("mt76x0: remove eeprom dependency from mt76x0_get_power_info") Signed-off-by: Lorenzo Bianconi Signed-off-by: Kalle Valo

wlcore: sdio: Fixup power on/off sequence

2019-01-22T16:23:49Z

During "wlan-up", we are programming the FW into the WiFi-chip. However, re-programming the FW doesn't work, unless a power cycle of the WiFi-chip is made in-between the programmings. To conform to this requirement and to fix the regression in a simple way, let's start by allowing that the SDIO card (WiFi-chip) may stay powered on (runtime resumed) when wl12xx_sdio_power_off() returns. The intent with the current code is to treat this scenario as an error, but unfortunate this doesn't work as expected, so let's fix this. The other part is to guarantee that a power cycle of the SDIO card has been completed when wl12xx_sdio_power_on() returns, as to allow the FW programming to succeed. However, relying solely on runtime PM to deal with this isn't sufficient. For example, userspace may prevent runtime suspend via sysfs for the device that represents the SDIO card, leading to that the mmc core also keeps it powered on. For this reason, let's instead do a brute force power cycle in wl12xx_sdio_power_on(). Fixes: 728a9dc61f13 ("wlcore: sdio: Fix flakey SDIO runtime PM handling") Signed-off-by: Ulf Hansson Tested-by: Tony Lindgren Tested-by: Anders Roxell Signed-off-by: Ulf Hansson Signed-off-by: Kalle Valo

virt_wifi: fix error return code in virt_wifi_newlink()

2019-01-19T08:12:16Z

Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: c7cdba31ed8b ("mac80211-next: rtnetlink wifi simulation device") Signed-off-by: Wei Yongjun Signed-off-by: Johannes Berg

mac80211_hwsim: check that n_limits makes sense

2019-01-19T08:10:30Z

Under certain circumstances, radios created via netlink could have n_limits be zero and no possible interface types, which makes no sense. Reject this early to prevent a WARN_ON() in cfg80211. Fixes: 99e3a44bac37 ("mac80211_hwsim: allow setting iftype support") Reported-by: syzbot+73fd8b0aa60c67fa4b60@syzkaller.appspotmail.com Signed-off-by: Johannes Berg

iwlwifi: make IWLWIFI depend on CFG80211

2019-01-16T18:09:05Z

Since IWLWIFI doesn't depend on MAC80211 anymore, it needs to depend on CFG80211, because it uses a few symbols from it. Add the dependency on CFG80211 accordingly. Additionally, make IWLWIFI_LEDS depend on IWLMVM or IWLDVM, since it doesn't need mac80211 but must be used for these. Fixes: aca432f06b8a ("iwlwifi: make MVM and DVM depend on MAC80211") Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo