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

libertas: fix suspend and resume for SDIO connected cards

2018-09-09T08:32:29+00:00

commit 7444a8092906ed44c09459780c56ba57043e39b1 upstream.

Prior to commit 573185cc7e64 ("mmc: core: Invoke sdio func driver's PM
callbacks from the sdio bus"), the MMC core used to call into the power
management functions of SDIO clients itself and removed the card if the
return code was non-zero. IOW, the mmc handled errors gracefully and didn't
upchain them to the pm core.

Since this change, the mmc core relies on generic power management
functions which treat all errors as a reason to cancel the suspend
immediately. This causes suspend attempts to fail when the libertas
driver is loaded.

To fix this, power down the card explicitly in if_sdio_suspend() when we
know we're about to lose power and return success. Also set a flag in these
cases, and power up the card again in if_sdio_resume().

Fixes: 573185cc7e64 ("mmc: core: Invoke sdio func driver's PM callbacks from the sdio bus")
Cc: 
Signed-off-by: Daniel Mack 
Reviewed-by: Chris Ball 
Reviewed-by: Ulf Hansson 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

b43/leds: Ensure NUL-termination of LED name string

2018-09-05T07:29:49+00:00

commit 2aa650d1950fce94f696ebd7db30b8830c2c946f upstream.

strncpy might not NUL-terminate the string, if the name equals the buffer size.
Use strlcpy instead.

Signed-off-by: Michael Buesch 
Cc: stable@vger.kernel.org
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

b43legacy/leds: Ensure NUL-termination of LED name string

2018-09-05T07:29:49+00:00

commit 4d77a89e3924b12f4a5628b21237e57ab4703866 upstream.

strncpy might not NUL-terminate the string, if the name equals the buffer size.
Use strlcpy instead.

Signed-off-by: Michael Buesch 
Cc: stable@vger.kernel.org
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

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