linux-stable.git/drivers/net/wireless, branch v5.0.2

ath9k: Avoid OF no-EEPROM quirks without qca,no-eeprom

2019-03-13T21:01:31+00:00

commit ce938231bd3b1d7af3cbd8836f084801090470e1 upstream.

ath9k_of_init() function[0] was initially written on the assumption that
if someone had an explicit ath9k OF node that "there must be something
wrong, why would someone add an OF node if everything is fine"[1]
(Quoting Martin Blumenstingl )

"it turns out it's not that simple. with your requirements I'm now aware
of two use-cases where the current code in ath9k_of_init() doesn't work
without modifications"[1]

The "your requirements" Martin speaks of is the result of the fact that I
have a device (PowerCloud Systems CR5000) has some kind of default - not
unique mac address - set and requires to set the correct MAC address via
mac-address devicetree property, however:

"some cards come with a physical EEPROM chip [or OTP] so "qca,no-eeprom"
should not be set (your use-case). in this case AH_USE_EEPROM should be
set (which is the default when there is no OF node)"[1]

The other use case is:

the firmware on some PowerMac G5 seems to add a OF node for the ath9k
card automatically. depending on the EEPROM on the card AH_NO_EEP_SWAP
should be unset (which is the default when there is no OF node). see [3]

After this patch to ath9k_of_init() the new behavior will be:

    if there's no OF node then everything is the same as before
    if there's an empty OF node then ath9k will use the hardware EEPROM
      (before ath9k would fail to initialize because no EEPROM data was
      provided by userspace)
    if there's an OF node with only a MAC address then ath9k will use
      the MAC address and the hardware EEPROM (see the case above)
    with "qca,no-eeprom" EEPROM data from userspace will be requested.
      the behavior here will not change
[1]

Martin provides additional background on EEPROM swapping[1].

Thanks to Christian Lamparter  for all his help on
troubleshooting this issue and the basis for this patch.

[0]https://elixir.bootlin.com/linux/v4.20-rc7/source/drivers/net/wireless/ath/ath9k/init.c#L615
[1]https://github.com/openwrt/openwrt/pull/1645#issuecomment-448027058
[2]https://github.com/openwrt/openwrt/pull/1613
[3]https://patchwork.kernel.org/patch/10241731/

Fixes: 138b41253d9c ("ath9k: parse the device configuration from an OF node")
Reviewed-by: Martin Blumenstingl 
Tested-by: Martin Blumenstingl 
Signed-off-by: Daniel F. Dickinson 
Signed-off-by: Kalle Valo 
Cc: Christian Lamparter 
Signed-off-by: Greg Kroah-Hartman

mac80211_hwsim: propagate genlmsg_reply return code

2019-02-22T12:27:22+00:00

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:47+00:00

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:16+00:00

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:06+00:00

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:50+00:00

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:11+00:00

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:49+00:00

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:16+00:00

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:30+00:00

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