linux-stable.git/drivers/net/wireless, branch v5.0.6 Linux kernel stable tree mt76x02u: use usb_bulk_msg to upload firmware 2019-04-03T04:27:39+00:00 Stanislaw Gruszka sgruszka@redhat.com 2019-02-11T08:16:14+00:00 debaa517c16c65247ec753324e16ccd7c26e858c commit 5de4db8fcb6d6fc7d9064c22841211790c0ab81b upstream. We don't need to send firmware data asynchronously, much simpler is just use synchronous usb_bulk_msg(). [ stable note: this patch was originally developed as cleanup, but it remove incorrect usage of page_frag_alloc(): alloc more than PAGE_SIZE and create not ARCH_DMA_MINALIGN dma buffers needed at least for performance reason. Was tested on 5.0 and 4.20, see https://bugzilla.kernel.org/show_bug.cgi?id=202673 and https://bugzilla.kernel.org/show_bug.cgi?id=202241 ] Tested-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 5de4db8fcb6d6fc7d9064c22841211790c0ab81b upstream.

We don't need to send firmware data asynchronously, much simpler is just
use synchronous usb_bulk_msg().

[ stable note: this patch was originally developed as cleanup, but it
remove incorrect usage of page_frag_alloc(): alloc more than PAGE_SIZE
and create not ARCH_DMA_MINALIGN dma buffers needed at least for
performance reason. Was tested on 5.0 and 4.20, see
https://bugzilla.kernel.org/show_bug.cgi?id=202673 and
https://bugzilla.kernel.org/show_bug.cgi?id=202241 ]

Tested-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
libertas_tf: don't set URB_ZERO_PACKET on IN USB transfer 2019-03-23T19:11:23+00:00 Lubomir Rintel lkundrak@v3.sk 2019-02-10T19:47:49+00:00 bd05a30753ebd84004f132bf20aca8c94625bec6 commit 607076a904c435f2677fadaadd4af546279db68b upstream. It doesn't make sense and the USB core warns on each submit of such URB, easily flooding the message buffer with tracebacks. Analogous issue was fixed in regular libertas driver in commit 6528d8804780 ("libertas: don't set URB_ZERO_PACKET on IN USB transfer"). Cc: stable@vger.kernel.org Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Reviewed-by: Steve deRosier <derosier@cal-sierra.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 607076a904c435f2677fadaadd4af546279db68b upstream.

It doesn't make sense and the USB core warns on each submit of such
URB, easily flooding the message buffer with tracebacks.

Analogous issue was fixed in regular libertas driver in commit 6528d8804780
("libertas: don't set URB_ZERO_PACKET on IN USB transfer").

Cc: stable@vger.kernel.org
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mt76: fix corrupted software generated tx CCMP PN 2019-03-23T19:11:19+00:00 Felix Fietkau nbd@nbd.name 2019-01-25T16:59:06+00:00 9d67c5e995dabb1e75740e01e6d4f202d68a285b commit 906d2d3f874a54183df5a609fda180adf0462428 upstream. Since ccmp_pn is u8 *, the second half needs to start at array index 4 instead of 0. Fixes a connection stall after a certain amount of traffic Fixes: 23405236460b9 ("mt76: fix transmission of encrypted management frames") Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 906d2d3f874a54183df5a609fda180adf0462428 upstream.

Since ccmp_pn is u8 *, the second half needs to start at array index 4
instead of 0. Fixes a connection stall after a certain amount of traffic

Fixes: 23405236460b9 ("mt76: fix transmission of encrypted management frames")
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ath9k: Avoid OF no-EEPROM quirks without qca,no-eeprom 2019-03-13T21:01:31+00:00 Daniel F. Dickinson cshored@thecshore.com 2018-12-22T06:09:13+00:00 3dfe7538f80acf0edf33ae4ae4f639c86e3a3be5 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 <martin.blumenstingl@googlemail.com>) "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 <chunkeey@gmail.com> 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 <martin.blumenstingl@googlemail.com> Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Daniel F. Dickinson <cshored@thecshore.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Cc: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <martin.blumenstingl@googlemail.com>)

"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 <chunkeey@gmail.com> 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 <martin.blumenstingl@googlemail.com>
Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Daniel F. Dickinson <cshored@thecshore.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Cc: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mac80211_hwsim: propagate genlmsg_reply return code 2019-02-22T12:27:22+00:00 Li RongQing lirongqing@baidu.com 2019-02-19T05:12:40+00:00 17407715240456448e4989bee46ffc93991add83 genlmsg_reply can fail, so propagate its return code Signed-off-by: Li RongQing <lirongqing@baidu.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
genlmsg_reply can fail, so propagate its return code

Signed-off-by: Li RongQing <lirongqing@baidu.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
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 David S. Miller davem@davemloft.net 2019-02-19T01:40:47+00:00 92a8c299a75d1397551bc067f6a26211346abf15 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 <davem@davemloft.net> 
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 <davem@davemloft.net>
mt76x0u: fix suspend/resume 2019-02-07T16:32:16+00:00 Stanislaw Gruszka sgruszka@redhat.com 2019-02-06T14:34:16+00:00 d04ca383860bef90a0dab4eb397907f7f05e839e 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 <sgruszka@redhat.com> Acked-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> 
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 <sgruszka@redhat.com>
Acked-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
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 David S. Miller davem@davemloft.net 2019-02-04T17:12:06+00:00 3e5a7c981464fd592f10a62c911001c174d46c12 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 <davem@davemloft.net> 
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 <davem@davemloft.net>
ath10k: correct bus type for WCN3990 2019-01-31T16:56:50+00:00 Brian Norris briannorris@chromium.org 2019-01-29T23:12:01+00:00 2c2008a63e482654ab137c84d3c61c03b75e7df6 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 <briannorris@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> 
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 <briannorris@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
mt76x0: eeprom: fix chan_vs_power map in mt76x0_get_power_info 2019-01-31T16:56:11+00:00 Lorenzo Bianconi lorenzo.bianconi@redhat.com 2019-01-27T11:15:49+00:00 05672636b339c557feb6a98b2f2034be790aa4fb 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 <lorenzo.bianconi@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> 
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 <lorenzo.bianconi@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>