linux/drivers/net/wireless/broadcom, branch v4.19

b43: fix DMA error related regression with proprietary firmware

2018-09-20T11:58:39Z

In commit 66cffd6daab7 ("b43: fix transmit failure when VT is switched"), a condition is noted where the network controller needs to be reset. Note that this situation happens when running the open-source firmware (http://netweb.ing.unibs.it/~openfwwf/), plus a number of other special conditions. for a different card model, it is reported that this change breaks operation running the proprietary firmware (https://marc.info/?l=linux-wireless&m=153504546924558&w=2). Rather than reverting the previous patch, the code is tweaked to avoid the reset unless the open-source firmware is being used. Fixes: 66cffd6daab7 ("b43: fix transmit failure when VT is switched") Cc: Stable # 4.18+ Cc: Taketo Kabe Reported-and-tested-by: D. Prabhu Signed-off-by: Larry Finger Signed-off-by: Kalle Valo

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

2018-08-09T15:44:54Z

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

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

2018-08-09T15:22:33Z

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

brcmfmac: fix brcmf_wiphy_wowl_params() NULL pointer dereference

2018-08-09T15:06:20Z

The kernel BUG happens when wowl is enabled from firmware. In brcmf_wiphy_wowl_params(), cfg is a NULL pointer because it is drvr->config returned from wiphy_to_cfg(), and drvr->config is not set yet. To fix it, set drvr->config before brcmf_setup_wiphy() which calls brcmf_wiphy_wowl_params(). Fixes: 856d5a011c86 ("brcmfmac: allocate struct brcmf_pub instance using wiphy_new()") Signed-off-by: Winnie Chang Signed-off-by: Chi-Hsien Lin Signed-off-by: Kalle Valo

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

2018-08-06T00:36:01Z

Kalle Valo says: ==================== wireless-drivers-next patches for 4.19 This time a bigger pull request as we have two new Mediatek drivers MT76x2u (CONFIG_MT76x2U) and MT76x0U (CONFIG_MT76x0U). Also iwlwifi got support for the new IEEE 802.11ax standard, the successor for 802.11ac. And naturally smaller new features and bugfixes all over. Major changes: wcn36xx * fix WEP in client mode wil6210 * add support for Talyn-MB (Talyn ver 2.0) device * add support for enhanced DMA firmware feature iwlwifi * implement 802.11ax D2.0 * support for the new 22560 device family * new PCI IDs for 22000 and 22560 qtnfmac * implement cfg80211 power management callback * enable multiple SSIDs scan support * qtnfmac: implement basic WoWLAN support mt7601u * fall back to software encryption for hw unsupported ciphers * enable 802.11 Management Frame Protection (MFP) mt76 * support setting RTS threshold * add USB support * add support for MT76x2u devices * add support for MT76x0U devices mwifiex * allow user space to set all other IEs except WMM IE rsi * add firmware support for AP+BT dual mode ==================== Signed-off-by: David S. Miller

Merge ra.kernel.org:/pub/scm/linux/kernel/git/davem/net

2018-08-02T17:55:32Z

The BTF conflicts were simple overlapping changes. The virtio_net conflict was an overlap of a fix of statistics counter, happening alongisde a move over to a bonafide statistics structure rather than counting value on the stack. Signed-off-by: David S. Miller

brcmfmac: specify some features per firmware version

2018-07-31T07:22:16Z

Some features supported by firmware aren't advertised and there is no way for a driver to query them. This includes e.g. monitor mode details. Most firmwares support monitor interface but only the latest ones /announce/ it with a "monitor" flag in the "cap" iovar. There isn't any reliable detection method for older firmwares (BRCMF_C_MONITOR was tried but "it only indicates the core part of the stack supports"). Similarly support for tagging monitor frames and building radiotap headers can't be reliably detected for all firmwares. This commit adds table that allows mapping features to firmware version. It adds mappings for 43602a1 and 4366b1 firmwares from linux-firmware.git. Both were confirmed to be passing monitor frames. Signed-off-by: Rafał Miłecki Reviewed-by: Arend van Spriel Signed-off-by: Kalle Valo

brcmfmac: fix regression in parsing NVRAM for multiple devices

2018-07-25T07:30:36Z

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

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

2018-07-24T04:30:03Z

Kalle Valo says: ==================== wireless-drivers-next patches for 4.19 The first set of patches for 4.19. Only smaller features and bug fixes, not really anything major. Also included are changes to include/linux/bitfield.h, we agreed with Johannes that it makes sense to apply them via wireless-drivers-next. Major changes: ath10k * support channel 173 * fix spectral scan for QCA9984 and QCA9888 chipsets ath6kl * add support for Dell Wireless 1537 ti wlcore * add support for runtime PM * enable runtime PM autosuspend support qtnfmac * support changing MAC address * enable source MAC address randomization support libertas * fix suspend and resume for SDIO cards mt76 * add software DFS radar pattern detector for mt76x2 based devices ==================== Signed-off-by: David S. Miller

brcmfmac: update STA info struct to the v5

2018-07-04T15:08:06Z

That struct is used when querying firmware for the STA. It seem is has been changing during the time. Luckily its format seems to be backward compatible starting with v2 (the only breakage was v1 -> v2). The version that was supported by brcmfmac so far was v4. It was what 43602a1 and 4366b1 firmwares (7.35.177.56 and 10.10.69.3309 accordingly) were using. It also seems to be used by early 4366c0 firmwares (10.10.69.6908 and 10.10.69.69017). The problem appears when switching to the 10.10.122.20 firmware. It uses v5 and instead of falling back to v4 when submitted buffer isn't big enough it fallbacks to the v3. To receive all v4 specific info with the newest firmware we have to submit a struct (buffer) that matches v5. Signed-off-by: Rafał Miłecki Acked-by: Arend van Spriel Signed-off-by: Kalle Valo