Commit Graph

563 Commits

Author SHA1 Message Date
Dan Haab
4282ff17e5 brcmfmac: support STA info struct v7
The newest firmwares provide STA info using v7 of the struct. As v7
isn't backward compatible, a union is needed.

Even though brcmfmac does not use any of the new info it's important to
provide the proper struct buffer. Without this change new firmwares will
fallback to the very limited v3 instead of something in between such as
v4.

Signed-off-by: Dan Haab <dan.haab@luxul.com>
Reviewed-by: Rafał Miłecki <rafal@milecki.pl>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-29 17:31:52 +02:00
Priit Laes
d5a433556d b43: Use cordic algorithm from kernel library
Kernel library has a common cordic algorithm which is identical
to internally implemented one, so use it and drop the duplicate
implementation.

Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Priit Laes <plaes@plaes.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-29 17:30:50 +02:00
Larry Finger
8ea3819c0b b43: Fix error in cordic routine
The cordic routine for calculating sines and cosines that was added in
commit 6f98e62a9f ("b43: update cordic code to match current specs")
contains an error whereby a quantity declared u32 can in fact go negative.

This problem was detected by Priit Laes who is switching b43 to use the
routine in the library functions of the kernel.

Fixes: 9865045403 ("b43: make cordic common (LP-PHY and N-PHY need it)")
Reported-by: Priit Laes <plaes@plaes.org>
Cc: Rafał Miłecki <zajec5@gmail.com>
Cc: Stable <stable@vger.kernel.org> # 2.6.34
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Priit Laes <plaes@plaes.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-29 17:30:49 +02:00
Priit Laes
ea3edda9dd brcmsmac: Use cordic-related macros from common cordic library
Current driver includes macro that is available from general cordic
library. Use that and drop unused duplicate and unneeded internal
definitions.

Signed-off-by: Priit Laes <plaes@plaes.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-29 17:30:49 +02:00
David S. Miller
b1bf78bfb2 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 2018-11-24 17:01:43 -08:00
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
David S. Miller
4a5a553dde brcmfmac: Use standard SKB list accessors in brcmf_sdiod_sglist_rw.
Instead of direct SKB list pointer accesses.

The loops in this function had to be rewritten to accommodate this
more easily.

The first loop iterates now over the target list in the outer loop,
and triggers an mmc data operation when the per-operation limits are
hit.

Then after the loops, if we have any residue, we trigger the last
and final operation.

For the page aligned workaround, where we have to copy the read data
back into the original list of SKBs, we use a two-tiered loop.  The
outer loop stays the same and iterates over pktlist, and then we have
an inner loop which uses skb_peek_next().  The break logic has been
simplified because we know that the aggregate length of the SKBs in
the source and destination lists are the same.

This change also ends up fixing a bug, having to do with the
maintainance of the seg_sz variable and how it drove the outermost
loop.  It begins as:

	seg_sz = target_list->qlen;

ie. the number of packets in the target_list queue.  The loop
structure was then:

	while (seq_sz) {
		...
		while (not at end of target_list) {
			...
			sg_cnt++
			...
		}
		...
		seg_sz -= sg_cnt;

The assumption built into that last statement is that sg_cnt counts
how many packets from target_list have been fully processed by the
inner loop.  But this not true.

If we hit one of the limits, such as the max segment size or the max
request size, we will break and copy a partial packet then contine
back up to the top of the outermost loop.

With the new loops we don't have this problem as we don't guard the
loop exit with a packet count, but instead use the progression of the
pkt_next SKB through the list to the end.  The general structure is:

	sg_cnt = 0;
	skb_queue_walk(target_list, pkt_next) {
		pkt_offset = 0;
		...
		sg_cnt++;
		...
		while (pkt_offset < pkt_next->len) {
			pkt_offset += sg_data_size;
			if (queued up max per request)
				mmc_submit_one();
		}
	}
	if (sg_cnt)
		mmc_submit_one();

The variables that maintain where we are in the MMC command state such
as req_sz, sg_cnt, and sgl are reset when we emit one of these full
sized requests.

Signed-off-by: David S. Miller <davem@davemloft.net>
2018-11-10 16:31:15 -08:00
Rafał Miłecki
ae5848cb45 brcmutil: print invalid chanspec when WARN-ing
On one of my devices I got WARNINGs when brcmfmac tried to decode
chanspec. I couldn't tell if it was some unsupported format or just a
malformed value passed by a firmware.

Print chanspec value so it's possible to debug a possible problem.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06 19:03:20 +02:00
Ali MJ Al-Nasrawy
96fca788e5 brcmsmac: never log "tid x is not agg'able" by default
This message greatly spams the log under heavy Tx of frames with BK access
class which is especially true when operating as AP. It is also not informative
as the "agg'ablity" of TIDs are set once and never change.
Fix this by logging only in debug mode.

Signed-off-by: Ali MJ Al-Nasrawy <alimjalnasrawy@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06 19:01:00 +02:00
Colin Ian King
e966a79c2f brcmfmac: fix spelling mistake "Retreiving" -> "Retrieving"
Trivial fix to spelling mistake in brcmf_err error message.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06 18:56:57 +02:00
Hans de Goede
29ec3394f0 brcmfmac: Fix ccode from EFI nvram when necessary
In some cases the EFI-var stored nvram contains "ccode=ALL" or "ccode=XV"
to specify "worldwide" compatible settings, but these 2 ccode-s do not work
properly.

I've tested the different known "worldwide" ccode-s used in various nvram
sources with the latest firmwares from linux-firmware for various brcmfmac
models, here is a simplified (*) table with what each setting results in:

ALL: 12-14 disab, U-NII-1, U-NII-2 no-IR/radar, U-NII-3
XV:  12-14 no-IR, disables all 5G channels
XY:  12-13 enab, 14 disab, U-NII-1 enab, U-NII-2 no-IR/radar, U-NII-3 disab
X2:  12-13 no-IR, 14 dis, U-NII-1 no-IR, U-NII-2 no-IR/radar, U-NII-3 no-IR

Where 12,13,14 are 2.4G channels 12-14 and U-NII-1/2/3 are the 3 different
5G channel groups. no-IR is no-Initiate-Radiation, we will never send on
these channels without first having received valid wifi traffic there.

This immediately shows that both ALL and XV are not as worldwide as we want
them to be. ALL causes channels 12 and 13 to not be available and XV causes
all 5GHz channels to not be available. Also ALL unconditionally enables the
U-NII-1 and U-NII-3 5G groups, while we really should be using no-IR for
these.

This commit replace XV and ALL with X2, which allows usage of chan 12-13
and 5G channels, but only after receiving valid wifi traffic there first.

Note that this configure the firmware's channel limits, the kernels own
regulatory restrictions based on e.g. regulatory info received from the
access-point, will be applied on top of this.

This fixes channels 12+13 not working on the Asus T200TA and the Lenovo
Mixx 2 8 and 5G channels not working on the Asus T100HA.

This has been tested on the following models: Acer Iconia Tab8 w1-810,
Acer One 10, Asus T100CHI, Asus T100HA, Asus T100TA, Asus T200TA and a
Lenovo Mixx 2 8.

*) There are some exceptions to this table:
1) On really old firmware e.g. linux-firmware's 2011 brcmfmac4330-sdio.bin
   ALL really means all, unconditionally enabling everything
2) The exact meaning might be influenced by setting the regrev nvram var.
   Specifically using ccode=XV + regrev=1 on brcmfmac43241b4 leads to:
   12-14 no-ir, U-NII-1 no-ir, U-NII-2 no-ir/radar, U-NII-3 no-ir
   But only on the brcmfmac43241b4 and not on e.g. the brcmfmac43340

Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06 18:51:41 +02:00
Hans de Goede
ce2e6db554 brcmfmac: Add support for getting nvram contents from EFI variables
Various X86 laptops with a SDIO attached brcmfmac wifi chip, store the
nvram contents in a special EFI variable. This commit adds support for
getting nvram directly from this EFI variable, without the user needing
to manually copy it.

This makes Wifi / Bluetooth work out of the box on these devices instead of
requiring manual setup.

This has been tested on the following models: Acer Iconia Tab8 w1-810,
Acer One 10, Asus T100CHI, Asus T100HA, Asus T100TA, Asus T200TA and a
Lenovo Mixx 2 8.

Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06 18:51:40 +02:00
Hans de Goede
55e491edbf brcmfmac: Cleanup brcmf_fw_request_done()
The "cur" variable is now only used for a debug print and we already
print the same info from brcmf_fw_complete_request(), so the debug print
does not provide any extra info and we can remove it.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06 18:50:27 +02:00
Hans de Goede
bd1e82bb42 brcmfmac: Set board_type from DMI on x86 based machines
For x86 based machines, set the board_type used for nvram file selection
based on the DMI sys-vendor and product-name strings.

Since on some models these strings are too generic, this commit also adds
a quirk table overriding the strings for models listed in that table.

The board_type setting is used to load the board-specific nvram file with
a board-specific name so that we can ship files for each supported board
in linux-firmware.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06 18:50:17 +02:00
Hans de Goede
0ad4b55b2f brcmfmac: Set board_type used for nvram file selection to machine-compatible
For of/devicetree using machines, set the board_type used for nvram file
selection to the first string listed in the top-level's node compatible
string, aka the machine-compatible as used by of_machine_is_compatible().

The board_type setting is used to load the board-specific nvram file with
a board-specific name so that we can ship files for each supported board
in linux-firmware.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06 18:50:16 +02:00
Hans de Goede
eae8e50669 brcmfmac: Add support for first trying to get a board specific nvram file
The nvram files which some brcmfmac chips need are board-specific. To be
able to distribute these as part of linux-firmware, so that devices with
such a wifi chip will work OOTB, multiple (one per board) versions must
co-exist under /lib/firmware.

This commit adds support for callers of the brcmfmac/firmware.c code to
pass in a board_type parameter through the request structure.

If that parameter is set then the code will first try to load
chipmodel.board_type.txt before falling back to the old chipmodel.txt name.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06 18:50:15 +02:00
Hans de Goede
5b587496dc brcmfmac: Remove recursion from firmware load error handling
Before this commit brcmf_fw_request_done would call
brcmf_fw_request_next_item to load the next item, which on an error would
call brcmf_fw_request_done, which if the error is recoverable (*) will
then continue calling brcmf_fw_request_next_item for the next item again
which on an error will call brcmf_fw_request_done again...

This does not blow up because we only have a limited number of items so
we never recurse too deep. But the recursion is still quite ugly and
frankly is giving me a headache, so lets fix this.

This commit fixes this by removing brcmf_fw_request_next_item and by
making brcmf_fw_get_firmwares and brcmf_fw_request_done directly call
firmware_request_nowait resp. firmware_request themselves.

*) brcmf_fw_request_nvram_done fallback path succeeds or
   BRCMF_FW_REQF_OPTIONAL is set

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06 18:50:14 +02:00
Hans de Goede
a1a3b76216 brcmfmac: Remove firmware-loading code duplication
brcmf_fw_request_next_item and brcmf_fw_request_done both have identical
code to complete the fw-request depending on the item-type.

This commit adds a new brcmf_fw_complete_request helper removing this code
duplication.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-11-06 18:50:14 +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
Winnie Chang
27a8aea130 brcmfmac: fix brcmf_wiphy_wowl_params() NULL pointer dereference
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: 856d5a011c ("brcmfmac: allocate struct brcmf_pub instance using wiphy_new()")
Signed-off-by: Winnie Chang <winnie.chang@cypress.com>
Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-08-09 18:06:20 +03:00
David S. Miller
b9a7f2ee56 Merge tag 'wireless-drivers-next-for-davem-2018-08-05' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
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 <davem@davemloft.net>
2018-08-05 17:36:01 -07:00
David S. Miller
89b1698c93 Merge ra.kernel.org:/pub/scm/linux/kernel/git/davem/net
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 <davem@davemloft.net>
2018-08-02 10:55:32 -07:00
Rafał Miłecki
1e591c56a6 brcmfmac: specify some features per firmware version
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 <rafal@milecki.pl>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-07-31 10:22:16 +03:00
Rafał Miłecki
299b6365a3 brcmfmac: fix regression in parsing NVRAM for multiple devices
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 <adityaxavier@gmail.com>
Fixes: 2baa3aaee2 ("brcmfmac: introduce brcmf_fw_alloc_request() function")
Cc: stable@vger.kernel.org # v4.17+
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-07-25 10:30:36 +03:00
David S. Miller
a527d3f728 Merge tag 'wireless-drivers-next-for-davem-2018-07-23' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
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 <davem@davemloft.net>
2018-07-23 21:30:03 -07:00
Rafał Miłecki
07b1ae4687 brcmfmac: update STA info struct to the v5
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 <rafal@milecki.pl>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-07-04 18:08:06 +03:00
Rafał Miłecki
4b4a8d808c brcmfmac: define more bits for the flags of struct brcmf_sta_info_le
That struct is passed by a firmware when querying for STA info. Flags
are used to indicate what info could be obtained.

These new defines may allow passing more info to the cfg80211 in the
future. They had been obtained from Broadcom's SDK file wlioctl_defs.h
used by DD-WRT.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-07-04 18:07:25 +03:00