Commit Graph

4 Commits

Author SHA1 Message Date
Rafał Miłecki
7f00ee2bbc brcmfmac: use correct skb freeing helper when deleting flowring
Flowrings contain skbs waiting for transmission that were passed to us
by netif. It means we checked every one of them looking for 802.1x
Ethernet type. When deleting flowring we have to use freeing function
that will check for 802.1x type as well.

Freeing skbs without a proper check was leading to counter not being
properly decreased. This was triggering a WARNING every time
brcmf_netdev_wait_pend8021x was called.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Arend van Spriel <arend@broadcom.com>
Cc: stable@vger.kernel.org # 4.5+
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-09-27 18:47:55 +03:00
Arend Van Spriel
bc98164136 brcmfmac: fix memory leak in brcmf_flowring_add_tdls_peer()
In the error paths in brcmf_flowring_add_tdls_peer() the allocated
resource should be freed.

Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-09-26 20:35:53 +03:00
Hante Meuleman
19c8f421a6 brcmfmac: Increase nr of supported flowrings.
New generation devices have firmware which has more than 256 flowrings.
E.g. following debugging message comes from 14e4:4365 BCM4366:
[  194.606245] brcmfmac: brcmf_pcie_init_ringbuffers Nr of flowrings is 264

At various code places (related to flowrings) we were using u8 which
could lead to storing wrong number or infinite loops when indexing with
this type. This issue was quite easy to spot in brcmf_flowring_detach
where it led to infinite loop e.g. on failed initialization.

This patch switches code to proper types and increases the maximum
number of supported flowrings to 512.

Originally this change was sent in September 2015, but back it was
causing a regression on BCM43602 resulting in:
Unable to handle kernel NULL pointer dereference at virtual address ...

The reason for this regression was missing update (s/u8/u16) of struct
brcmf_flowring_ring. This problem was handled in 9f64df9 ("brcmfmac: Fix
bug in flowring management."). Starting with that it's safe to apply
this original patch as it doesn't cause a regression anymore.

This patch fixes an infinite loop on BCM4366 which is supported since
4.4 so it makes sense to apply it to stable 4.4+.

Cc: <stable@vger.kernel.org> # 4.4+
Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2016-02-25 11:59:22 +02:00
Kalle Valo
05491d2ccf brcm80211: move under broadcom vendor directory
Part of reorganising wireless drivers directory and Kconfig. Note that I had to
edit Makefiles from subdirectories to use the new location.

Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2015-11-18 11:24:22 +02:00