linux/drivers/net/wireless, branch v3.17

brcmfmac: Fix off by one bug in brcmf_count_20mhz_channels()

2014-09-23T14:48:26Z

In the brcmf_count_20mhz_channels function we are looping through a list of channels received from firmware. Since the index of the first channel is 0 the condition leads to an off by one bug. This is causing us to hit the WARN_ON_ONCE(1) calls in the brcmu_d11n_decchspec function, which is how I discovered the bug. Introduced by: commit b48d891676f756d48b4d0ee131e4a7a5d43ca417 ("brcmfmac: rework wiphy structure setup") Acked-by: Arend van Spriel Signed-off-by: Emil Goode Signed-off-by: John W. Linville

ath9k: Fix NULL pointer dereference on early irq

2014-09-22T20:02:15Z

The ah struct might not have been initialized when interrupt comes so check for it. Signed-off-by: Wojciech Dubowik Signed-off-by: John W. Linville

ath9k_htc: fix random decryption failure

2014-09-15T19:09:26Z

In v3.15 the driver stopped to accept network packets after successful authentification, which could be worked around by passing the nohwcrypt=1 module parameter. This was not reproducible by everyone, and showed random behaviour in some tests. It was caused by an uninitialized variable introduced in 4ed1a8d4a257 ("ath9k_htc: use ath9k_cmn_rx_accept") and used in 341b29b9cd2f ("ath9k_htc: use ath9k_cmn_rx_skb_postprocess"). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=78581 Fixes: 341b29b9cd2f ("ath9k_htc: use ath9k_cmn_rx_skb_postprocess") Signed-off-by: Johannes Stezenbach Signed-off-by: John W. Linville

brcmfmac: handle IF event for P2P_DEVICE interface

2014-09-15T19:09:26Z

The firmware notifies about interface changes through the IF event which has a NO_IF flag that means host can ignore the event. This behaviour was introduced in the driver by: commit 2ee8382fc6c763c76396a6aaff77a27089eed3aa Author: Arend van Spriel Date: Sat Aug 10 12:27:24 2013 +0200 brcmfmac: ignore IF event if firmware indicates it It turns out that the IF event for the P2P_DEVICE also has this flag set, but the event should not be ignored in this scenario. The mentioned commit caused a regression in 3.12 kernel in creation of the P2P_DEVICE interface. Cc: # 3.14, 3.16 Reviewed-by: Hante Meuleman Reviewed-by: Franky (Zhenhui) Lin Reviewed-by: Daniel (Deognyoun) Kim Reviewed-by: Pieter-Paul Giesberts Signed-off-by: Arend van Spriel Signed-off-by: John W. Linville

brcmfmac: obtain ifp through wdev structure

2014-09-15T19:09:26Z

For P2P_DEVICE interface the function brcmf_cfg80211_update_proto_addr_mode() resulted in a crash, because it assumed wdev->netdev would be valid. The ifp should be obtained through the driver vif structure which contains the wireless_dev. Reviewed-by: Hante Meuleman Reviewed-by: Franky (Zhenhui) Lin Reviewed-by: Daniel (Deognyoun) Kim Reviewed-by: Pieter-Paul Giesberts Signed-off-by: Arend van Spriel Signed-off-by: John W. Linville

brcmfmac: conditionally compile firmware protocol source code

2014-09-15T19:09:26Z

The host-interface can select which protocol implementation it needs. Selecting PCIe will include the msgbuf protocol and selecting USB and/or SDIO will include the bcdc protocol. The PCIe kconfig option assures the dependencies for msgbuf are met, ie. HAS_DMA. Reported-by: Geert Uytterhoeven Reviewed-by: Franky (Zhenhui) Lin Reviewed-by: Hante Meuleman Reviewed-by: Daniel (Deognyoun) Kim Reviewed-by: Pieter-Paul Giesberts Signed-off-by: Arend van Spriel Signed-off-by: John W. Linville

brcmfmac: Fix memory leak and missing assignment.

2014-09-15T19:09:25Z

The function brcmf_enable_bw40_2g contains a memory leak. The function is also missing initialisation of one of the members of ch struct, which can lead to warning but this has no impact on result. Reviewed-by: Arend Van Spriel Reviewed-by: Franky (Zhenhui) Lin Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Daniel (Deognyoun) Kim Signed-off-by: Hante Meuleman Signed-off-by: Arend van Spriel Signed-off-by: John W. Linville

Revert "ath9k: Calculate sleep duration"

2014-09-11T18:17:20Z

This reverts commit 09ebb810927a110e4c354beb20308830d108a54b. ath9k_hw_set_sta_beacon_timers() configures AR_TIM_PERIOD with the beacon interval. Before this commit, the sleepduration was never greater than the beacon interval. But now, the behavior has changed. For example, with an AP that uses a beacon interval of 100: ath: phy9: next beacon 61128704 ath: phy9: beacon period 204800 ath: phy9: DTIM period 204800 If the sleepduration is calculated based on the listen time, then the bmiss threshold should also be changed since the HW would be in sleep state for a longer time, but that is not done currently. To avoid configuring a higher beacon interval based on the sleepduration, revert to the original behavior. Power consumption is not a problem since PS is disabled in ath9k anyway. Cc: stable@vger.kernel.org Cc: Rajkumar Manoharan Signed-off-by: Sujith Manoharan Signed-off-by: John W. Linville

Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes

2014-09-09T19:00:06Z

iwlwifi: mvm: fix an overflow in iwl_mvm_get_signal_strength

2014-09-08T16:47:22Z

The idea here is to translate a value of 0 received from the firmware to the lowest rssi figure. As rx_status->chain_signal is a signed byte the lowest possible value is -128 and not -256. -256 was causing 0 to get stored in the signed byte. Signed-off-by: Eyal Shapira Reviewed-by: Johannes Berg Signed-off-by: Emmanuel Grumbach