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

brcmfmac: Use firmware_request_nowarn for the clm_blob

2019-04-05T20:34:51+00:00

[ Upstream commit 4ad0be160544ffbdafb7cec39bb8e6dd0a97317a ]

The linux-firmware brcmfmac firmware files contain an embedded table with
per country allowed channels and strength info.

For recent hardware these versions of the firmware are specially build for
linux-firmware, the firmware files directly available from Cypress rely on
a separate clm_blob file for this info.

For some unknown reason Cypress refuses to provide the standard firmware
files + clm_blob files it uses elsewhere for inclusion into linux-firmware,
instead relying on these special builds with the clm_blob info embedded.
This means that the linux-firmware firmware versions often lag behind,
but I digress.

The brcmfmac driver does support the separate clm_blob file and always
tries to load this. Currently we use request_firmware for this. This means
that on any standard install, using the standard combo of linux-kernel +
linux-firmware, we will get a warning:
"Direct firmware load for ... failed with error -2"

On top of this, brcmfmac itself prints: "no clm_blob available (err=-2),
device may have limited channels available".

This commit switches to firmware_request_nowarn, fixing almost any brcmfmac
device logging the warning (it leaves the brcmfmac info message in place).

Signed-off-by: Hans de Goede 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin

cross-tree: phase out dma_zalloc_coherent()

2019-01-08T12:58:37+00:00

We already need to zero out memory for dma_alloc_coherent(), as such
using dma_zalloc_coherent() is superflous. Phase it out.

This change was generated with the following Coccinelle SmPL patch:

@ replace_dma_zalloc_coherent @
expression dev, size, data, handle, flags;
@@

-dma_zalloc_coherent(dev, size, handle, flags)
+dma_alloc_coherent(dev, size, handle, flags)

Suggested-by: Christoph Hellwig 
Signed-off-by: Luis Chamberlain 
[hch: re-ran the script on the latest tree]
Signed-off-by: Christoph Hellwig

brcmfmac: Fix access point mode

2018-12-20T06:49:01+00:00

Since commit 1204aa17f3b4 ("brcmfmac: set WIPHY_FLAG_HAVE_AP_SME flag")
the Raspberry Pi 3 A+ (BCM43455) isn't able to operate in AP mode with
hostapd (device_ap_sme=1 use_monitor=0):

brcmfmac: brcmf_cfg80211_stop_ap: setting AP mode failed -52

So add the missing mgmt_stypes for AP mode to fix this.

Fixes: 1204aa17f3b4 ("brcmfmac: set WIPHY_FLAG_HAVE_AP_SME flag")
Suggested-by: Arend van Spriel 
Signed-off-by: Stefan Wahren 
Acked-by: Arend van Spriel 
Signed-off-by: Kalle Valo

brcmfmac: fix roamoff=1 modparam

2018-12-20T06:47:53+00:00

When the update_connect_param callback is set, nl80211 expects the flag
WIPHY_FLAG_SUPPORTS_FW_ROAM to be set as well. However, this flag is
only set when modparam roamoff=0, while the callback is set
unconditionally. Since commit 7f9a3e150ec7 this causes a warning in
wiphy_register, which breaks brcmfmac.

Disable the update_connect_param callback when roamoff=0 to fix this.

Fixes: 7f9a3e150ec7 ("nl80211: Update ERP info using NL80211_CMD_UPDATE_CONNECT_PARAMS")
Cc: Stable  # 4.19+
Signed-off-by: Jonas Gorski 
Signed-off-by: Stijn Tintel 
Signed-off-by: Kalle Valo

b43: remove set but not used variables 'tx_pwr_state,tmp2'

2018-12-13T15:02:17+00:00

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/net/wireless/broadcom/b43/phy_n.c: In function 'b43_nphy_op_recalc_txpower':
drivers/net/wireless/broadcom/b43/phy_n.c:5898:7: warning:
 variable 'tx_pwr_state' set but not used [-Wunused-but-set-variable]

drivers/net/wireless/broadcom/b43/phy_n.c:6047:20: warning:
 variable 'tmp2' set but not used [-Wunused-but-set-variable]

'tx_pwr_state' never used since introduction in commit
8615eb2870f1 ("b43: N-PHY: support setting custom TX power")

'tmp2' not used any more since commit c002831a07dd ("b43: N-PHY: use helper
for checking IPA")

Signed-off-by: YueHaibing 
Signed-off-by: Kalle Valo

brcmfmac: fix false-positive -Wmaybe-unintialized warning

2018-12-13T14:59:00+00:00

When CONFIG_NO_AUTO_INLINE is set, we get a false-postive warning
for the brcmf_fw_request_nvram_done() function, after gcc figures
out that brcmf_fw_nvram_from_efi() might not set the 'data_len'
variable, but fails to notice that it always returns NULL:

drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c: In function 'brcmf_fw_request_nvram_done':
drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:560:11: error: 'data_len' may be used uninitialized in this function [-Werror=maybe-uninitialized]

Mark it 'inline' to force gcc to understand this.

Fixes: ce2e6db554fa ("brcmfmac: Add support for getting nvram contents from EFI variables")
Signed-off-by: Arnd Bergmann 
Reviewed-by: Hans de Goede 
Signed-off-by: Kalle Valo

brcmfmac: disable command decode in sdio_aos

2018-12-13T14:57:27+00:00

AOS is a part of the SDIOD core that becomes active when the rest of
SDIOD is sleeping to keep SDIO bus alive responding to reduced set of
commands.

Transaction between AOS and SDIOD is not protected, and if cmd 52 is
received in AOS and in the middle of response state changed from AOS to
SDIOD, response is corrupted and it causes to SDIO Host controller to
hang.

Command decode for below chips are disabled in this commit:
 - 4339
 - 4345
 - 4354
 - 4373

Reviewed-by: Arend van Spriel 
Signed-off-by: Wright Feng 
Signed-off-by: Double Lo 
Signed-off-by: Madhan Mohan R 
Signed-off-by: Chi-Hsien Lin 
Signed-off-by: Kalle Valo

brcmfmac: 4373 save-restore support

2018-12-13T14:57:26+00:00

Use chipcommon sr_control0 register to check 4373 sr support.

Reviewed-by: Arend van Spriel 
Signed-off-by: Chi-Hsien Lin 
Signed-off-by: Kalle Valo

brcmfmac: update 43012 F2 watermark setting to fix DMA Error during UDP RX Traffic

2018-12-13T14:57:22+00:00

The number of words that the read FIFO has to contain except
the end of frame before sends data back to the host.
Max watermark = (512B - 2* (BurstLength))/4 =
(512 - 128)/4 = 384/4 = 0x60
so if burst length (i.e. BurstLength = 64) is increased,
watermark has to be reduced. This is the optimal setting for this chip.

Reviewed-by: Arend van Spriel 
Signed-off-by: Naveen Gupta 
Signed-off-by: Chi-Hsien Lin 
Signed-off-by: Kalle Valo

brcmfmac: allow GCI core enumuration

2018-12-13T14:57:20+00:00

GCI core is needed for ULP operation. Allow GCI core enumuration with
below changes:
 - Allow GCI to be added to core list even when it doesn't have a wrapper.
 - Allow 8K address space size.
 - Don't overwrite the address value when an additional size descriptor
   is in place.

Reviewed-by: Arend van Spriel 
Signed-off-by: Chi-Hsien Lin 
Signed-off-by: Kalle Valo