kernel/drivers/net/wireless/broadcom, branch linux-4.16.y

brcmfmac: Fix check for ISO3166 code

2018-03-20T10:07:58Z

The commit "regulatory: add NUL to request alpha2" increases the length of alpha2 to 3. This causes a regression on brcmfmac, because brcmf_cfg80211_reg_notifier() expect valid ISO3166 codes in the complete array. So fix this accordingly. Fixes: 657308f73e67 ("regulatory: add NUL to request alpha2") Signed-off-by: Stefan Wahren Acked-by: Franky Lin Signed-off-by: Kalle Valo

brcmfmac: drop Inter-Access Point Protocol packets by default

2018-03-16T13:00:24Z

Testing brcmfmac with more recent firmwares resulted in AP interfaces not working in some specific setups. Debugging resulted in discovering support for IAPP in Broadcom's firmwares. Older firmwares were only generating 802.11f frames. Newer ones like: 1) 10.10 (TOB) (r663589) 2) 10.10.122.20 (r683106) for 4366b1 and 4366c0 respectively seem to also /respect/ 802.11f frames in the Tx path by performing a STA disassociation. This obsoleted standard and its implementation is something that: 1) Most people don't need / want to use 2) Can allow local DoS attacks 3) Breaks AP interfaces in some specific bridge setups To solve issues it can cause this commit modifies brcmfmac to drop IAPP packets. If affects: 1) Rx path: driver won't be sending these unwanted packets up. 2) Tx path: driver will reject packets that would trigger STA disassociation perfromed by a firmware (possible local DoS attack). It appears there are some Broadcom's clients/users who care about this feature despite the drawbacks. They can switch it on using a new module param. This change results in only two more comparisons (check for module param and check for Ethernet packet length) for 99.9% of packets. Its overhead should be very minimal. Signed-off-by: Rafał Miłecki Acked-by: Arend van Spriel Signed-off-by: Kalle Valo

brcmfmac: fix P2P_DEVICE ethernet address generation

2018-03-07T14:36:41Z

The firmware has a requirement that the P2P_DEVICE address should be different from the address of the primary interface. When not specified by user-space, the driver generates the MAC address for the P2P_DEVICE interface using the MAC address of the primary interface and setting the locally administered bit. However, the MAC address of the primary interface may already have that bit set causing the creation of the P2P_DEVICE interface to fail with -EBUSY. Fix this by using a random address instead to determine the P2P_DEVICE address. Cc: stable@vger.kernel.org # 3.10.y Reported-by: Hans de Goede Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Franky Lin Signed-off-by: Arend van Spriel Signed-off-by: Kalle Valo

brcmfmac: add possibility to obtain firmware error

2018-03-07T14:36:40Z

The feature module needs to evaluate the actual firmware error return upon a control command. This adds a flag to struct brcmf_if that the caller can set. This flag is checked to determine the error code that needs to be returned. Fixes: b69c1df47281 ("brcmfmac: separate firmware errors from i/o errors") Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Franky Lin Signed-off-by: Arend van Spriel Signed-off-by: Kalle Valo

brcmfmac: separate firmware errors from i/o errors

2018-01-24T16:02:39Z

When using the firmware api it can fail simply because firmware does not like the request or it fails due to issues in the host interface. Currently, there is only a single error code which is confusing. So adding a parameter to pass the firmware error separately and in case of a firmware error always return -EBADE to user-space. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Franky Lin Signed-off-by: Arend van Spriel Signed-off-by: Kalle Valo

brcmfmac: assure bcdc dcmd api does not return value > 0

2018-01-24T16:02:38Z

The protocol layer api defines callbacks for dongle commands. Although not really well documented these should only return an error code in case of an error, or 0 upon success. In the bcdc protocol it can return value above 0 and we carry a fix in the caller of the protocol layer api. This patch makes it adhere to the intent of the api as described above. Reviewed-by: Hante Meuleman Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Franky Lin Signed-off-by: Arend van Spriel Signed-off-by: Kalle Valo

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

2018-01-20T03:59:33Z

The BPF verifier conflict was some minor contextual issue. The TUN conflict was less trivial. Cong Wang fixed a memory leak of tfile->tx_array in 'net'. This is an skb_array. But meanwhile in net-next tun changed tfile->tx_arry into tfile->tx_ring which is a ptr_ring. Signed-off-by: David S. Miller

brcmfmac: fix CLM load error for legacy chips when user helper is enabled

2018-01-16T19:17:32Z

For legacy chips without CLM blob files, kernel with user helper function returns -EAGAIN when we request_firmware(), and then driver got failed when bringing up legacy chips. We expect the CLM blob file for legacy chip is not existence in firmware path, but the -ENOENT error is transferred to -EAGAIN in firmware_class.c with user helper. Because of that, we continue with CLM data currently present in firmware if getting error from doing request_firmware(). Cc: stable@vger.kernel.org # v4.15.y Reviewed-by: Arend van Spriel Signed-off-by: Wright Feng Signed-off-by: Kalle Valo

b43: Replace mdelay with usleep_range in b43_radio_2057_init_post

2018-01-11T19:54:01Z

b43_radio_2057_init_post is not called in an interrupt handler nor holding a spinlock. The function mdelay in it can be replaced with usleep_range, to reduce busy wait. Signed-off-by: Jia-Ju Bai Acked-by: Larry Finger Signed-off-by: Kalle Valo

brcmfmac: Use zeroing memory allocator than allocator/memset

2018-01-11T19:52:59Z

Use dma_zalloc_coherent for allocating zeroed memory and remove unnecessary memset function. Generated-by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci Suggested-by: Luis R. Rodriguez Signed-off-by: Himanshu Jha Signed-off-by: Kalle Valo