linux-stable.git/drivers/net/wireless, branch v3.17.2 Linux kernel stable tree Revert "ath9k_hw: reduce ANI firstep range for older chips" 2014-10-30T16:43:14+00:00 Felix Fietkau nbd@openwrt.org 2014-09-29T18:45:40+00:00 3465ae92c736884c9fcea3ddecd8c69b84576c7d commit 171cdab8c78bb169d9693d587e1d02d2dd5a0274 upstream. This reverts commit 09efc56345be4146ab9fc87a55c837ed5d6ea1ab I've received reports that this change is decreasing throughput in some rare conditions on an AR9280 based device Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 171cdab8c78bb169d9693d587e1d02d2dd5a0274 upstream.

This reverts commit 09efc56345be4146ab9fc87a55c837ed5d6ea1ab

I've received reports that this change is decreasing throughput in some
rare conditions on an AR9280 based device

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rt2800: correct BBP1_TX_POWER_CTRL mask 2014-10-30T16:43:14+00:00 Stanislaw Gruszka sgruszka@redhat.com 2014-09-24T09:24:54+00:00 e8beb3b22de84737fd823d6d04566dd45f9c8a98 commit 01f7feeaf4528bec83798316b3c811701bac5d3e upstream. Two bits control TX power on BBP_R1 register. Correct the mask, otherwise we clear additional bit on BBP_R1 register, what can have unknown, possible negative effect. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 01f7feeaf4528bec83798316b3c811701bac5d3e upstream.

Two bits control TX power on BBP_R1 register. Correct the mask,
otherwise we clear additional bit on BBP_R1 register, what can have
unknown, possible negative effect.

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iwlwifi: Add missing PCI IDs for the 7260 series 2014-10-30T16:43:10+00:00 Oren Givon oren.givon@intel.com 2014-09-17T07:31:56+00:00 44f8ea82ca4cd1e0eb1673aa2fb62eb28a4d6340 commit 4f08970f5284dce486f0e2290834aefb2a262189 upstream. Add 4 missing PCI IDs for the 7260 series. Signed-off-by: Oren Givon <oren.givon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 4f08970f5284dce486f0e2290834aefb2a262189 upstream.

Add 4 missing PCI IDs for the 7260 series.

Signed-off-by: Oren Givon <oren.givon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iwlwifi: mvm: disable BT Co-running by default 2014-10-30T16:43:10+00:00 Emmanuel Grumbach emmanuel.grumbach@intel.com 2014-09-21T09:45:34+00:00 02ee80194f44d678e1a560ba3fc267bf4f8f25c7 commit 9b60bb6d86496af1adc753795de2c12c4499868a upstream. The tables still contain dummy values. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 9b60bb6d86496af1adc753795de2c12c4499868a upstream.

The tables still contain dummy values.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
brcmfmac: Fix off by one bug in brcmf_count_20mhz_channels() 2014-09-23T14:48:26+00:00 Emil Goode emilgoode@gmail.com 2014-09-22T22:49:55+00:00 f8adaf0ae978252c9f7e29e96aefcd8fcaf806ba 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 <arend@broadcom.com> Signed-off-by: Emil Goode <emilgoode@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
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 <arend@broadcom.com>
Signed-off-by: Emil Goode <emilgoode@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k: Fix NULL pointer dereference on early irq 2014-09-22T20:02:15+00:00 Wojciech Dubowik Wojciech.Dubowik@neratec.com 2014-09-18T06:30:41+00:00 2ba7d144d39a596cf5d09390ee7de21cfb69cf2b The ah struct might not have been initialized when interrupt comes so check for it. Signed-off-by: Wojciech Dubowik <Wojciech.Dubowik@neratec.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
The ah struct might not have been initialized when
interrupt comes so check for it.

Signed-off-by: Wojciech Dubowik <Wojciech.Dubowik@neratec.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_htc: fix random decryption failure 2014-09-15T19:09:26+00:00 Johannes Stezenbach js@sig21.net 2014-09-12T20:36:51+00:00 d21ccfd0a60ea3dece3e1d142f52694abf87a0b1 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 <js@sig21.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
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 <js@sig21.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
brcmfmac: handle IF event for P2P_DEVICE interface 2014-09-15T19:09:26+00:00 Arend van Spriel arend@broadcom.com 2014-09-12T14:19:30+00:00 87c4790330810fe5caf0172d9320cf24ef19cebe 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 <arend@broadcom.com> 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: <stable@vger.kernel.org> # 3.14, 3.16 Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by: Daniel (Deognyoun) Kim <dekim@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
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 <arend@broadcom.com>
  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: <stable@vger.kernel.org> # 3.14, 3.16
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Reviewed-by: Daniel (Deognyoun) Kim <dekim@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
brcmfmac: obtain ifp through wdev structure 2014-09-15T19:09:26+00:00 Arend van Spriel arend@broadcom.com 2014-09-11T20:51:32+00:00 8f2b45971b32824b830a544ed1d179215770b1eb 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 <meuleman@broadcom.com> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by: Daniel (Deognyoun) Kim <dekim@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
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 <meuleman@broadcom.com>
Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Reviewed-by: Daniel (Deognyoun) Kim <dekim@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
brcmfmac: conditionally compile firmware protocol source code 2014-09-15T19:09:26+00:00 Arend van Spriel arend@broadcom.com 2014-09-11T20:51:31+00:00 f1d56039b58f6f786450a858b2c8d2459a3382cc 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 <geert@linux-m68k.org> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Daniel (Deognyoun) Kim <dekim@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
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 <geert@linux-m68k.org>
Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Daniel (Deognyoun) Kim <dekim@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>