Commit Graph
496 Commits
Author SHA1 Message Date
Rafał Miłecki d1fe6ad6f6 brcmfmac: fix reporting support for 160 MHz channels
Driver can report IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ so it's
important to provide valid & complete info about supported bands for
each channel. By default no support for 160 MHz should be assumed unless
firmware reports it for a given channel later.

This fixes info passed to the userspace. Without that change userspace
could try to use invalid channel and fail to start an interface.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Cc: stable@vger.kernel.org
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-16 15:10:18 +02:00
Rafał Miłecki 3401d42c7e brcmutil: really fix decoding channel info for 160 MHz bandwidth
Previous commit /adding/ support for 160 MHz chanspecs was incomplete.
It didn't set bandwidth info and didn't extract control channel info. As
the result it was also using uninitialized "sb" var.

This change has been tested for two chanspecs found to be reported by
some devices/firmwares:
1) 60/160 (0xee32)
   Before: chnum:50 control_ch_num:36
    After: chnum:50 control_ch_num:60
2) 120/160 (0xed72)
   Before: chnum:114 control_ch_num:100
    After: chnum:114 control_ch_num:120

Fixes: 330994e8e8 ("brcmfmac: fix for proper support of 160MHz bandwidth")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06 18:46:00 +02:00
Ali MJ Al-Nasrawy 2258ee58ba brcmsmac: AP mode: update beacon when TIM changes
Beacons are not updated to reflect TIM changes. This is not compliant with
power-saving client stations as the beacons do not have valid TIM and can
cause the network to stall at random occasions and to have highly variable
latencies.
Fix it by updating beacon templates on mac80211 set_tim callback.

Addresses an issue described in:
https://marc.info/?i=20180911163534.21312d08%20()%20manjaro

Signed-off-by: Ali MJ Al-Nasrawy <alimjalnasrawy@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-10-13 20:00:42 +03:00
David S. Miller 5057ef7f56 Merge tag 'wireless-drivers-next-for-davem-2018-10-07' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:

====================
wireless-drivers-next patches for 4.20

Second set of patches for 4.20. Heavy refactoring on mt76 continues
and the usual drivers in active development (iwlwifi, qtnfmac, ath10k)
getting new features. And as always, fixes and cleanup all over.

Major changes:

mt76

* more major refactoring to make it easier add new hardware support

* more work on mt76x0e support

* support for getting firmware version via ethtool

* add mt7650 PCI ID

iwlwifi

* HE radiotap cleanup and improvements

* reorder channel optimization for scans

* bump the FW API version

qtnfmac

* fixes for 'iw' output: rates for enabled SGI, 'dump station'

* expose more scan features to host: scan flush and dwell time

* inform cfg80211 when OBSS is not supported by firmware

wlcore

* add support for optional wakeirq

ath10k

* retrieve MAC address from system firmware if provided

* support extended board data download for dual-band QCA9984

* extended per sta tx statistics support via debugfs

* average ack rssi support for data frames

* speed up QCA6174 and QCA9377 firmware download using diag Copy
  Engine

* HTT High Latency mode support needed by SDIO and USB support

* get STA power save state via debugfs

ath9k

* add reset functionality for airtime station debugfs file
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
2018-10-07 10:31:24 -07:00
YueHaibing a7dd5d7c2d b43: remove set but not used variable 'wl'
Fixes gcc '-Wunused-but-set-variable' warning:

drivers/net/wireless/broadcom/b43/main.c: In function 'b43_one_core_detach':
drivers/net/wireless/broadcom/b43/main.c:5496:17: warning:
 variable 'wl' set but not used [-Wunused-but-set-variable]

After commit 644aa4d620 ("b43: remove list of IEEE 802.11 devices")
'wl' is not used any more.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-10-05 11:38:06 +03:00
Chung-Hsien Hsu fbf0700096 brcmfmac: fix full timeout waiting for action frame on-channel tx
The driver sends an action frame down and waits for a completion signal
triggered by the received BRCMF_E_ACTION_FRAME_OFF_CHAN_COMPLETE event
to continue the process. However, the action frame could be transmitted
either on the current channel or on an off channel. For the on-channel
case, only BRCMF_E_ACTION_FRAME_COMPLETE event will be received when
the frame is transmitted, which make the driver always wait a full
timeout duration. This patch has the completion signal be triggered by
receiving the BRCMF_E_ACTION_FRAME_COMPLETE event for the on-channel
case.

This change fixes WFA p2p certification 5.1.19 failure.

Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com>
Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-10-05 11:29:42 +03:00
Chung-Hsien Hsu edb6d6885b brcmfmac: reduce timeout for action frame scan
Finding a common channel to send an action frame out is required for
some action types. Since a loop with several scan retry is used to find
the channel, a short wait time could be considered for each attempt.
This patch reduces the wait time from 1500 to 450 msec for each action
frame scan.

This patch fixes the WFA p2p certification 5.1.20 failure caused by the
long action frame send time.

Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com>
Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-10-05 11:29:41 +03:00
David S. Miller 6f41617bf2 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
Minor conflict in net/core/rtnetlink.c, David Ahern's bug fix in 'net'
overlapped the renaming of a netlink attribute in net-next.

Signed-off-by: David S. Miller <davem@davemloft.net>
2018-10-03 21:00:17 -07:00
David S. Miller d793fb4682 Merge tag 'wireless-drivers-next-for-davem-2018-10-02' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:

====================
wireless-drivers-next patches for 4.20

First set of new features for 4.20. mt76 driver is going through major
refactoring and that's why there are so many mt76 patches. iwlwifi is
also under heavy development and smaller changes to other drivers.

Also wireless-drivers was merged to fix a conflict between the two trees.

Major changes:

ath10k

* limit available channels via DT ieee80211-freq-limit

wil6210

* add 802.11r Fast Roaming support for AP and station modes

* add support for channel 4

iwlwifi

* new FW API handling

* some improvements in the PCI recovery mechanism

* enable a new scanning feature;

* continued work on HE (mostly radiotap)

* TKIP implementation in new devices

* work continues for new 22560 hardware

mt76

* add support for Alfa AWUS036ACM

* lots of refactoring to make it easier to add new hardware support

* prepare for adding mt76x0e (pci-e variant) support

* add CONFIG_MT76x0E kconfig symbol

brcmfmac

* add support CYW89342 mini-PCIe device

* add 4-way handshake offload detection for FT-802.1X

* enable NL80211_EXT_FEATURE_CQM_RSSI_LIST

* fix for proper support of 160MHz bandwidth

rtl8xxxu

* add rtl8188ctv support
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
2018-10-02 11:46:29 -07:00
Colin Ian King 297fab130c b43: fix spelling mistake "hw_registred" -> "hw_registered"
Trivial fix to spelling mistake struct field name, rename it.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-10-01 18:41:34 +03:00
Takashi Iwai 6c3efbe77b brcmsmac: Use kvmalloc() for ucode allocations
The ucode chunk might be relatively large and the allocation with
kmalloc() may fail occasionally.  Since the data isn't DMA-transferred
but by manual loops, we can use vmalloc instead of kmalloc.
For a better performance, though, kvmalloc() would be the best choice
in such a case, so let's replace with it.

Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1103431
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-09-20 15:11:36 +03:00
YueHaibing a8254fa4ba brcmfmac: remove set but not used variables 'sfdoff' and 'pad_size'
Fixes gcc '-Wunused-but-set-variable' warning:

drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c: In function 'brcmf_sdio_rxglom':
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:1466:11: warning:
 variable 'sfdoff' set but not used [-Wunused-but-set-variable]

drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c: In function 'brcmf_sdio_bus_preinit':
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:3408:7: warning:
 variable 'pad_size' set but not used [-Wunused-but-set-variable]

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-09-20 15:11:07 +03:00
zhong jiang 761cb7cdef brcm80211: remove redundant condition check before debugfs_remove_recursive
debugfs_remove_recursive has taken IS_ERR_OR_NULL into account. So just
remove the condition check before debugfs_remove_recursive.

Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-09-20 15:10:16 +03:00
Arend van Spriel 59c2a30d36 brcmfmac: increase buffer for obtaining firmware capabilities
When obtaining the firmware capability a buffer is provided of 512
bytes. However, if all features in firmware are supported the buffer
needs to be 565 bytes as otherwise truncated information is retrieved
from firmware. Increasing the buffer to 768 bytes on stack.

Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-09-20 15:09:31 +03:00
Arend van Spriel 330994e8e8 brcmfmac: fix for proper support of 160MHz bandwidth
Decoding of firmware channel information was not complete for 160MHz
support. This resulted in the following warning:

  WARNING: CPU: 2 PID: 2222 at .../broadcom/brcm80211/brcmutil/d11.c:196
	brcmu_d11ac_decchspec+0x2e/0x100 [brcmutil]
  Modules linked in: brcmfmac(O) brcmutil(O) sha256_generic cfg80211 ...
  CPU: 2 PID: 2222 Comm: kworker/2:0 Tainted: G           O
  4.17.0-wt-testing-x64-00002-gf1bed50 #1
  Hardware name: Dell Inc. Latitude E6410/07XJP9, BIOS A07 02/15/2011
  Workqueue: events request_firmware_work_func
  RIP: 0010:brcmu_d11ac_decchspec+0x2e/0x100 [brcmutil]
  RSP: 0018:ffffc90000047bd0 EFLAGS: 00010206
  RAX: 000000000000e832 RBX: ffff8801146fe910 RCX: ffff8801146fd3c0
  RDX: 0000000000002800 RSI: 0000000000000070 RDI: ffffc90000047c30
  RBP: ffffc90000047bd0 R08: 0000000000000000 R09: ffffffffa0798c80
  R10: ffff88012bca55e0 R11: ffff880110a4ea00 R12: ffff8801146f8000
  R13: ffffc90000047c30 R14: ffff8801146fe930 R15: ffff8801138e02e0
  FS:  0000000000000000(0000) GS:ffff88012bc80000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f18ce8b8070 CR3: 000000000200a003 CR4: 00000000000206e0
  Call Trace:
   brcmf_setup_wiphybands+0x212/0x780 [brcmfmac]
   brcmf_cfg80211_attach+0xae2/0x11a0 [brcmfmac]
   brcmf_attach+0x1fc/0x4b0 [brcmfmac]
   ? __kmalloc+0x13c/0x1c0
   brcmf_pcie_setup+0x99b/0xe00 [brcmfmac]
   brcmf_fw_request_done+0x16a/0x1f0 [brcmfmac]
   request_firmware_work_func+0x36/0x60
   process_one_work+0x146/0x350
   worker_thread+0x4a/0x3b0
   kthread+0x102/0x140
   ? process_one_work+0x350/0x350
   ? kthread_bind+0x20/0x20
   ret_from_fork+0x35/0x40
  Code: 66 90 0f b7 07 55 48 89 e5 89 c2 88 47 02 88 47 03 66 81 e2 00 38
	66 81 fa 00 18 74 6e 66 81 fa 00 20 74 39 66 81 fa 00 10 74 14 <0f>
	0b 66 25 00 c0 74 20 66 3d 00 c0 75 20 c6 47 04 01 5d c3 66
  ---[ end trace 550c46682415b26d ]---
  brcmfmac: brcmf_construct_chaninfo: Ignoring unexpected firmware channel 50

This patch adds the missing stuff to properly handle this.

Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-09-20 15:09:30 +03:00
Larry Finger 2823c8716c b43: fix DMA error related regression with proprietary firmware
In commit 66cffd6daa ("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: 66cffd6daa ("b43: fix transmit failure when VT is switched")
Cc: Stable <stable@vger.kernel.org> # 4.18+
Cc: Taketo Kabe <kabe@sra-tohoku.co.jp>
Reported-and-tested-by: D. Prabhu <d.praabhu@gmail.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-09-20 14:58:39 +03:00
David S. Miller 776f07ee30 brcmfmac: Use __skb_peek().
Instead of direct SKB list pointer accesses.

In these situations, we absolutely know that the SKB queue in question
is non-empty.

Signed-off-by: David S. Miller <davem@davemloft.net>
2018-09-10 10:06:54 -07:00
Igor Stoppa 7e41fb5045 wireless: remove unnecessary unlikely()
Both WARN_ON() and WARN_ON_ONCE() already contain unlikely().

Signed-off-by: Igor Stoppa <igor.stoppa@huawei.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: Christian Lamparter <chunkeey@googlemail.com>
Cc: Michal Kazior <michal.kazior@tieto.com>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Linux Wireless Mailing List <linux-wireless@vger.kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-09-04 11:16:33 +03:00
Rasmus Villemoes cb18e2e9ec brcmfmac: fix wrong strnchr usage
strnchr takes arguments in the order of its name: string, max bytes to
read, character to search for. Here we're passing '\n' aka 10 as the
buffer size, and searching for sizeof(buf) aka BRCMF_DCMD_SMLEN aka
256 (aka '\0', since it's implicitly converted to char) within those 10
bytes.

Just interchanging the last two arguments would still leave a bug,
because if we've been successful once, there are not sizeof(buf)
characters left after the new value of p.

Since clmver is immediately afterwards passed as a %s argument, I assume
that it is actually a properly nul-terminated string. For that case, we
have strreplace().

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-08-31 18:48:02 +03:00
Chung-Hsien Hsu a858376cdb brcmfmac: add 4-way handshake offload detection for FT-802.1X
Add 4-way handshake offload detection for FT with EAP authentication.

Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com>
Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-08-31 18:44:41 +03:00
Chung-Hsien Hsu 4ad298da93 brcmfmac: add FT-based AKMs in brcmf_set_key_mgmt() for FT support
Add WLAN_AKM_SUITE_FT_8021X and WLAN_AKM_SUITE_FT_PSK in
brcmf_set_key_mgmt() for FT support.

Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com>
Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-08-31 18:44:40 +03:00
Jia-Shyr Chuang 2fef681a4c brcmfmac: add CYW89342 mini-PCIe device
CYW89342 is a 2x2 MIMO, 802.11a/b/g/n/ac for WLAN. It is a member of
4355/4359 family.

Signed-off-by: Jia-Shyr Chuang <saint.chuang@cypress.com>
Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-08-31 18:44:08 +03:00
Varsha Rao 9e9e11d832 brcmsmac: Remove extra parentheses
Remove the unnecessary parentheses to fix the clang warning of
extraneous parentheses.

Signed-off-by: Varsha Rao <rvarsha016@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-08-31 18:41:27 +03:00
Michael Büsch 4d77a89e39 b43legacy/leds: Ensure NUL-termination of LED name string
strncpy might not NUL-terminate the string, if the name equals the buffer size.
Use strlcpy instead.

Signed-off-by: Michael Buesch <m@bues.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-08-09 18:44:54 +03:00
Michael Büsch 2aa650d195 b43/leds: Ensure NUL-termination of LED name string
strncpy might not NUL-terminate the string, if the name equals the buffer size.
Use strlcpy instead.

Signed-off-by: Michael Buesch <m@bues.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-08-09 18:22:33 +03:00