linux-stable.git/drivers/net/wireless, branch linux-3.17.y

brcmfmac: Fix bitmap malloc bug in msgbuf.

2015-01-08T18:27:46+00:00

commit 333c2aa029b847051a2db76a6ca59f699a520030 upstream.

Reviewed-by: Arend Van Spriel 
Reviewed-by: Pieter-Paul Giesberts 
Signed-off-by: Hante Meuleman 
Signed-off-by: Arend van Spriel 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: check TLV flag before trying to use hotspot firmware commands

2014-12-06T23:57:33+00:00

commit 5ac6c72e594471acfa5b00210c51d533a73413ad upstream.

Older firmwares do not provide support for the HOT_SPOT_CMD command.
Check for the appropriate TLV flag that declares hotspot support in
the firmware to prevent a firmware assertion failure that can be
triggered from the userspace,

Signed-off-by: Luciano Coelho 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: ROC - bug fixes around time events and locking

2014-12-06T23:57:33+00:00

commit a6cc5163149532734b84c86cbffa4994e527074b upstream.

Don't add the time event to the list. We added it several
times the same time event, which leads to an infinite loop
when walking the list.

Since we (currently) don't support more than one ROC for STA
vif at a time, enforce this and don't add the time event
to any list.

We were also missing the locking of the mutex which led to
a lockdep splat - fix that.

Signed-off-by: Matti Gottlieb 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: pcie: fix prph dump length

2014-12-06T23:57:31+00:00

commit 87dd634ae72bb8f6d0dd12f1cbbc67c7da6dba3b upstream.

The length counting previously done had an error in it, causing
the length down the data dumping function to be shorter than it
should be, causing the end of the data to get truncated off and
lost.

Fixes: 67c65f2cf710 ("iwlwifi: dump periphery registers to fw-error-dump")
Signed-off-by: Liad Kaufman 
Reviewed-by: Johannes Berg 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

rt2x00: do not align payload on modern H/W

2014-12-06T23:57:31+00:00

commit cfd9167af14eb4ec21517a32911d460083ee3d59 upstream.

RT2800 and newer hardware require padding between header and payload if
header length is not multiple of 4.

For historical reasons we also align payload to to 4 bytes boundary, but
such alignment is not needed on modern H/W.

Patch fixes skb_under_panic problems reported from time to time:

https://bugzilla.kernel.org/show_bug.cgi?id=84911
https://bugzilla.kernel.org/show_bug.cgi?id=72471
http://marc.info/?l=linux-wireless&m=139108549530402&w=2
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1087591

Panic happened because we eat 4 bytes of skb headroom on each
(re)transmission when sending frame without the payload and the header
length not being multiple of 4 (i.e. QoS header has 26 bytes). On such
case because paylad_aling=2 is bigger than header_align=0 we increase
header_align by 4 bytes. To prevent that we could change the check to:

	if (payload_length && payload_align > header_align)
		header_align += 4;

but not aligning payload at all is more effective and alignment is not
really needed by H/W (that has been tested on OpenWrt project for few
years now).

Reported-and-tested-by: Antti S. Lankila 
Debugged-by: Antti S. Lankila 
Reported-by: Henrik Asp 
Originally-From: Helmut Schaa 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

brcmfmac: don't include linux/unaligned/access_ok.h

2014-12-06T23:57:28+00:00

commit a1d69c60c44134f64945bbf6a6dfda22eaf4a214 upstream.

This is a specific implementation,  is the
multiplexer that has the arch-specific knowledge of which
of the implementations needs to be used, so include that.

This issue was revealed by kbuild testing
when  was added in 
resulting in redefinition of get_unaligned_be16 (and
probably others).

Reported-by: Fengguang Wu 
Signed-off-by: Johannes Berg 
Signed-off-by: Arend van Spriel 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

brcmfmac: fix error handling of irq_of_parse_and_map

2014-12-06T23:57:28+00:00

commit 4c69f05eaa428e37890daf88b86a567ce615570b upstream.

Return value of irq_of_parse_and_map() is unsigned int, with 0
indicating failure, so testing for negative result never works.

Signed-off-by: Dmitry Torokhov 
Acked-by: Arend van Spriel 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

brcmfmac: fix conversion of channel width 20MHZ_NOHT

2014-12-06T23:57:28+00:00

commit 0cd75b19899fd86b51a6480fb8c00dcd85a54591 upstream.

The function chandef_to_chanspec() failed when converting a
chandef with bandwidth set to NL80211_CHAN_WIDTH_20_NOHT. This
was reported by user running the device in AP mode.

------------[ cut here ]------------
WARNING: CPU: 0 PID: 304 at
	drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c:381
		chandef_to_chanspec.isra.11+0x158/0x184()

Modules linked in:

CPU: 0 PID: 304 Comm: hostapd Not tainted 3.16.0-rc7-abb+g64aa90f #8

[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (warn_slowpath_common+0x6c/0x8c)
[] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24)
[] (warn_slowpath_null) from [] (chandef_to_chanspec.isra.11+0x158/0x184)
[] (chandef_to_chanspec.isra.11) from [] (brcmf_cfg80211_start_ap+0x1e4/0x614)
[] (brcmf_cfg80211_start_ap) from [] (nl80211_start_ap+0x288/0x414)
[] (nl80211_start_ap) from [] (genl_rcv_msg+0x21c/0x38c)
[] (genl_rcv_msg) from [] (netlink_rcv_skb+0xac/0xc0)
[] (netlink_rcv_skb) from [] (genl_rcv+0x20/0x34)
[] (genl_rcv) from [] (netlink_unicast+0x150/0x20c)
[] (netlink_unicast) from [] (netlink_sendmsg+0x2b8/0x398)
[] (netlink_sendmsg) from [] (sock_sendmsg+0x84/0xa8)
[] (sock_sendmsg) from [] (___sys_sendmsg.part.29+0x268/0x278)
[] (___sys_sendmsg.part.29) from [] (__sys_sendmsg+0x4c/0x7c)
[] (__sys_sendmsg) from [] (ret_fast_syscall+0x0/0x44)
---[ end trace 965ee2158c9905a2 ]---

Reported-by: Pontus Fuchs 
Reviewed-by: Hante Meuleman 
Reviewed-by: Daniel (Deognyoun) Kim 
Reviewed-by: Franky (Zhenhui) Lin 
Reviewed-by: Pieter-Paul Giesberts 
Signed-off-by: Arend van Spriel 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k: Fix RTC_DERIVED_CLK usage

2014-12-06T23:57:22+00:00

commit 4e6ce4dc7ce71d0886908d55129d5d6482a27ff9 upstream.

Based on the reference clock, which could be 25MHz or 40MHz,
AR_RTC_DERIVED_CLK is programmed differently for AR9340 and AR9550.
But, when a chip reset is done, processing the initvals
sets the register back to the default value.

Fix this by moving the code in ath9k_hw_init_pll() to
ar9003_hw_override_ini(). Also, do this override for AR9531.

Signed-off-by: Miaoqing Pan 
Signed-off-by: Sujith Manoharan 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: fix RFkill while calibrating

2014-11-21T17:23:16+00:00

commit 31b8b343e019e0a0c57ca9c13520a87f9cab884b upstream.

If the RFkill interrupt fires while we calibrate, it would
make the firmware fail and the driver wasn't able to recover.
Change the flow so that the driver will kill the firmware
in that case.

Since we have now two flows that are calling
trans_stop_device (the RFkill interrupt and the
op_mode_mvm_start function) - we need to better sync this.
Use the STATUS_DEVICE_ENABLED in the pcie transport in an
atomic way to achieve this.

This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=86231

Reviewed-by: Johannes Berg 
Reviewed-by: Luciano Coelho 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman