linux-stable.git/drivers/net/wireless, branch v4.18.2

brcmfmac: fix regression in parsing NVRAM for multiple devices

2018-07-25T07:30:36+00:00

NVRAM is designed to work with Broadcom's SDK Linux kernel which fakes
PCI domain 0 for all internal MMIO devices. Since official Linux kernel
uses platform devices for that purpose there is a mismatch in numbering
PCI domains.

There used to be a fix for that problem but it was accidentally dropped
during the last firmware loading rework. That resulted in brcmfmac not
being able to extract device specific NVRAM content and all kind of
calibration problems.

Reported-by: Aditya Xavier 
Fixes: 2baa3aaee27f ("brcmfmac: introduce brcmf_fw_alloc_request() function")
Cc: stable@vger.kernel.org # v4.17+
Signed-off-by: Rafał Miłecki 
Acked-by: Arend van Spriel 
Signed-off-by: Kalle Valo

iwlwifi: add more card IDs for 9000 series

2018-07-25T07:29:29+00:00

Add new device IDs for the 9000 series.

Cc: stable@vger.kernel.org # 4.14
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Kalle Valo

Merge tag 'wireless-drivers-for-davem-2018-07-03' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers

2018-07-03T14:29:29+00:00

Kalle Valo says:

====================
wireless-drivers fixes for 4.18

First set of fixes for 4.18 and for numerous drivers. Something to mention
about is the wcn36xx fix which makes it possible to compile with gcc older than
4.4 (though I'm not sure if we even support those anymore).

qtnfmac

* coverity fix for a new commit in v4.18-rc1

rtlwifi

* fix kernel oops during driver removal

* fix firmware image corruption for rtl8821ae

brcmfmac

* fix crash if there's no firmware image

mwifiex

* a revert and a better fix for a new commit v4.18-rc1

mt7601u

* fix a recent regression about unnecessary warning about avg_rssi

wcn36xx

* convert testmode.c to plain ASCII

ath10k

* fix a firmware crash during bandwidth change
====================

Signed-off-by: David S. Miller

Merge ath-current from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git

2018-06-29T10:29:17+00:00

ath.git fixes for 4.18. Major changes:

wcn36xx

* convert testmode.c to plain ASCII

ath10k

* fix a firmware crash during bandwidth change

rtlwifi: rtl8821ae: fix firmware is not ready to run

2018-06-29T07:08:47+00:00

Without this patch, firmware will not run properly on rtl8821ae, and it
causes bad user experience. For example, bad connection performance with
low rate, higher power consumption, and so on.

rtl8821ae uses two kinds of firmwares for normal and WoWlan cases, and
each firmware has firmware data buffer and size individually. Original
code always overwrite size of normal firmware rtlpriv->rtlhal.fwsize, and
this mismatch causes firmware checksum error, then firmware can't start.

In this situation, driver gives message "Firmware is not ready to run!".

Fixes: fe89707f0afa ("rtlwifi: rtl8821ae: Simplify loading of WOWLAN firmware")
Signed-off-by: Ping-Ke Shih 
Cc: Stable  # 4.0+
Reviewed-by: Larry Finger 
Signed-off-by: Kalle Valo

wcn36xx: Remove Unicode Byte Order Mark from testcode

2018-06-28T09:28:35+00:00

Older gcc (< 4.4) doesn't like files starting with a Unicode BOM:

    drivers/net/wireless/ath/wcn36xx/testmode.c:1: error: stray ‘\357’ in program
    drivers/net/wireless/ath/wcn36xx/testmode.c:1: error: stray ‘\273’ in program
    drivers/net/wireless/ath/wcn36xx/testmode.c:1: error: stray ‘\277’ in program

Remove the BOM, the rest of the file is plain ASCII anyway.

Output of "file drivers/net/wireless/ath/wcn36xx/testmode.c" before:

    drivers/net/wireless/ath/wcn36xx/testmode.c: C source, UTF-8 Unicode (with BOM) text

and after:

    drivers/net/wireless/ath/wcn36xx/testmode.c: C source, ASCII text

Fixes: 87f825e6e246cee0 ("wcn36xx: Add support for Factory Test Mode (FTM)")
Signed-off-by: Geert Uytterhoeven 
Acked-by: Ramon Fried 
Signed-off-by: Kalle Valo

ath10k: update the phymode along with bandwidth change request

2018-06-28T09:27:05+00:00

In the case of Station connects to AP with narrower bandwidth at beginning.
And later the AP changes the bandwidth to winder bandwidth, the AP will
beacon with wider bandwidth IE, eg VHT20->VHT40->VHT80 or VHT40->VHT80.

Since the supported BANDWIDTH will be limited by the PHYMODE, so while
Station receives the bandwidth change request, it will also need to
reconfigure the PHYMODE setting to firmware instead of just configuring
the BANDWIDTH info, otherwise it'll trigger a firmware crash with
non-support bandwidth.

The issue was observed in WLAN.RM.4.4.1-00051-QCARMSWP-1, QCA6174 with
below scenario:

AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0 MHz)
disconnect from AP xxx for new auth to yyy
RX ReassocResp from xxx (capab=0x1111 status=0 aid=102)
associated

....

AP xxx changed bandwidth, new config is 5200 MHz, width 2 (5190/0 MHz)
AP xxx changed bandwidth, new config is 5200 MHz, width 3 (5210/0 MHz)

....

firmware register dump:
[00]: 0x05030000 0x000015B3 0x00987291 0x00955B31
[04]: 0x00987291 0x00060730 0x00000004 0x00000001
[08]: 0x004089F0 0x00955A00 0x000A0B00 0x00400000
[12]: 0x00000009 0x00000000 0x00952CD0 0x00952CE6
[16]: 0x00952CC4 0x0098E25F 0x00000000 0x0091080D
[20]: 0x40987291 0x0040E7A8 0x00000000 0x0041EE3C
[24]: 0x809ABF05 0x0040E808 0x00000000 0xC0987291
[28]: 0x809A650C 0x0040E948 0x0041FE40 0x004345C4
[32]: 0x809A5C63 0x0040E988 0x0040E9AC 0x0042D1A8
[36]: 0x8091D252 0x0040E9A8 0x00000002 0x00000001
[40]: 0x809FDA9D 0x0040EA58 0x0043D554 0x0042D554
[44]: 0x809F8B22 0x0040EA78 0x0043D554 0x00000001
[48]: 0x80911210 0x0040EAC8 0x00000010 0x004041D0
[52]: 0x80911154 0x0040EB28 0x00400000 0x00000000
[56]: 0x8091122D 0x0040EB48 0x00000000 0x00400600

Reported-by: Rouven Czerwinski 
Tested-by: Timur Kristóf 
Signed-off-by: Ryan Hsu 
Signed-off-by: Kalle Valo

mt7601u: remove warning when avg_rssi is zero

2018-06-24T17:01:38+00:00

It turned out that we can run calibration without already received
frames with RSSI data. In such case just don't update AGC register
and don't print the warning.

Fixes: b305a6ab0247 ("mt7601u: use EWMA to calculate avg_rssi")
Reported-by: Adam Borowski 
Signed-off-by: Stanislaw Gruszka 
Acked-by: Jakub Kicinski 
Signed-off-by: Kalle Valo

mwifiex: handle race during mwifiex_usb_disconnect

2018-06-24T17:00:46+00:00

Race condition is observed during rmmod of mwifiex_usb:

1. The rmmod thread will call mwifiex_usb_disconnect(), download
   SHUTDOWN command and do wait_event_interruptible_timeout(),
   waiting for response.

2. The main thread will handle the response and will do a
   wake_up_interruptible(), unblocking rmmod thread.

3. On getting unblocked, rmmod thread  will make rx_cmd.urb = NULL in
   mwifiex_usb_free().

4. The main thread will try to resubmit rx_cmd.urb in
   mwifiex_usb_submit_rx_urb(), which is NULL.

To fix this, move mwifiex_usb_free() from mwifiex_usb_disconnect
to mwifiex_unregister_dev(). Function mwifiex_unregister_dev() is
called after flushing the command and RX work queues.

Suggested-by: Brian Norris 
Signed-off-by: Ganapathi Bhat 
Reviewed-by: Brian Norris 
Signed-off-by: Kalle Valo

Revert "mwifiex: handle race during mwifiex_usb_disconnect"

2018-06-24T16:59:34+00:00

This reverts commit b817047ae70c0bd67b677b65d0d69d72cd6e9728.

We have a better fix for this issue, which will be sent on top
of this revert.

Signed-off-by: Ganapathi Bhat 
Signed-off-by: Kalle Valo