ath9k: Fix kernel panic in AR2427 in AP mode

don't do aggregation related stuff for 'AP mode client power save
handling' if aggregation is not enabled in the driver, otherwise it
will lead to panic because those data structures won't be never
intialized in 'ath_tx_node_init' if aggregation is disabled

EIP is at ath_tx_aggr_wakeup+0x37/0x80 [ath9k]
EAX: e8c09a20 EBX: f2a304e8 ECX: 00000001 EDX: 00000000
ESI: e8c085e0 EDI: f2a304ac EBP: f40e1ca4 ESP: f40e1c8c
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process swapper/1 (pid: 0, ti=f40e0000 task=f408e860
task.ti=f40dc000)
Stack:
0001e966 e8c09a20 00000000 f2a304ac e8c085e0 f2a304ac
f40e1cb0 f8186741
f8186700 f40e1d2c f922988d f2a304ac 00000202 00000001
c0b4ba43 00000000
0000000f e8eb75c0 e8c085e0 205b0001 34383220 f2a304ac
f2a30000 00010020
Call Trace:
[<f8186741>] ath9k_sta_notify+0x41/0x50 [ath9k]
[<f8186700>] ? ath9k_get_survey+0x110/0x110 [ath9k]
[<f922988d>] ieee80211_sta_ps_deliver_wakeup+0x9d/0x350
[mac80211]
[<c018dc75>] ? __module_address+0x95/0xb0
[<f92465b3>] ap_sta_ps_end+0x63/0xa0 [mac80211]
[<f9246746>] ieee80211_rx_h_sta_process+0x156/0x2b0
[mac80211]
[<f9247d1e>] ieee80211_rx_handlers+0xce/0x510 [mac80211]
[<c018440b>] ? trace_hardirqs_on+0xb/0x10
[<c056936e>] ? skb_queue_tail+0x3e/0x50
[<f9248271>] ieee80211_prepare_and_rx_handle+0x111/0x750
[mac80211]
[<f9248bf9>] ieee80211_rx+0x349/0xb20 [mac80211]
[<f9248949>] ? ieee80211_rx+0x99/0xb20 [mac80211]
[<f818b0b8>] ath_rx_tasklet+0x818/0x1d00 [ath9k]
[<f8187a75>] ? ath9k_tasklet+0x35/0x1c0 [ath9k]
[<f8187a75>] ? ath9k_tasklet+0x35/0x1c0 [ath9k]
[<f8187b33>] ath9k_tasklet+0xf3/0x1c0 [ath9k]
[<c0151b7e>] tasklet_action+0xbe/0x180

Cc: stable@kernel.org
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Reported-by: Ashwin Mendonca <ashwinloyal@gmail.com>
Tested-by: Ashwin Mendonca <ashwinloyal@gmail.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Merge branch 'master' of git://git./linux/kernel/git/padovan/bluetooth

Revert "Bluetooth: Increase HCI reset timeout in hci_dev_do_close"

This reverts commit e1b6eb3ccb0c2a34302a9fd87dd15d7b86337f23.

This was causing a delay of 10 seconds in the resume process of a Thinkpad
laptop. I'm afraid this could affect more devices once 3.2 is released.

Reported-by: Tomáš Janoušek <tomi@nomi.cz>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

iwlwifi: update SCD BC table for all SCD queues

Since we configure all the queues as CHAINABLE, we need to update the
byte count for all the queues, not only the AGGREGATABLE ones.

Not doing so can confuse the SCD and make the fw assert.

Cc: stable@vger.kernel.org
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Merge branch 'master' of git://git./linux/kernel/git/padovan/bluetooth

Revert "Bluetooth: Revert: Fix L2CAP connection establishment"

This reverts commit 4dff523a913197e3314c7b0d08734ab037709093.

It was reported that this patch cause issues when trying to connect to
legacy devices so reverting it.

Reported-by: David Fries <david@fries.net>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: Clear RFCOMM session timer when disconnecting last channel

When the last RFCOMM data channel is closed, a timer is normally set
up to disconnect the control channel at a later time.  If the control
channel disconnect command is sent with the timer pending, the timer
needs to be cancelled.

If the timer is not cancelled in this situation, the reference
counting logic for the RFCOMM session does not work correctly when the
remote device closes the L2CAP connection.  The session is freed at
the wrong time, leading to a kernel panic.

Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: Prevent uninitialized data access in L2CAP configuration

When configuring an ERTM or streaming mode connection, remote devices
are expected to send an RFC option in a successful config response.  A
misbehaving remote device might not send an RFC option, and the L2CAP
code should not access uninitialized data in this case.

Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

iwlwifi: allow to switch to HT40 if not associated

My previous patch
34a5b4b6af104cf18eb50748509528b9bdbc4036 iwlwifi: do not re-configure
HT40 after associated

Fix the case of HT40 after association on specified AP, but it break the
association for some APs and cause not able to establish connection.
We need to address HT40 before and after addociation.

CC: stable@vger.kernel.org #3.0+
Reported-by: Andrej Gelenberg <andrej.gelenberg@udo.edu>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Tested-by: Andrej Gelenberg <andrej.gelenberg@udo.edu>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlwifi: tx_sync only on PAN context

Ted reported that he couldn't connect to some APs
and bisected it to the tx_sync implementation.
Disable it for the BSS context to fix this issue.

Reported-by: Ted Ts'o <tytso@mit.edu>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mwifiex: avoid double list_del in command cancel path

Command cancel path cancels the current command and moves
it to free command queue. While doing that it deletes the
command entry from the pending list. This is not correct
as the entry has been already deleted from the pending
list at 'mwifiex_exec_next_cmd'. Fixing it.

Also making sure the stale command pointer is cleaned and
unaccessible for later use.

Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: fix max phy rate at rate control init

The stations always chooses 1Mbps for all trasmitting frames,
whenever the AP is configured to lock the supported rates.
As the max phy rate is always set with the 4th from highest phy rate,
this assumption might be wrong if we have less than that. Fix that.

Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Reported-by: Ajay Gummalla <agummalla@google.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

nfc: signedness bug in __nci_request()

wait_for_completion_interruptible_timeout() returns -ERESTARTSYS if
interrupted so completion_rc needs to be signed.  The current code
probably returns -ETIMEDOUT if we hit this situation, but after this
patch is applied it will return -ERESTARTSYS.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlwifi: do not set the sequence control bit is not needed

Check the IEEE80211_TX_CTL_ASSIGN_SEQ flag from mac80211, then decide how to
set the TX_CMD_FLG_SEQ_CTL_MSK bit. Setting the wrong bit in BAR frame whill
make the firmware to increment the sequence number which is incorrect and
cause unknown behavior.

CC: stable@vger.kernel.org #3.0+
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ssb: fix init regression with SoCs

This fixes a Data bus error on some SoCs. The first fix for this
problem did not solve it on all devices.
    commit 6ae8ec27868bfdbb815287bee8146acbefaee867
    Author: Rafał Miłecki <zajec5@gmail.com>
    Date:   Tue Jul 5 17:25:32 2011 +0200
        ssb: fix init regression of hostmode PCI core

In ssb_pcicore_fix_sprom_core_index() the sprom on the PCI core is
accessed, but the sprom only exists when the ssb bus is connected over
a PCI bus to the rest of the system and not when the SSB Bus is the
main system bus. SoCs sometimes have a PCI host controller and there
this code will not be executed, but there are some old SoCs with an PCI
controller in client mode around and ssb_pcicore_fix_sprom_core_index()
should not be called on these devices too. The PCI controller on these
devices are unused, but without this fix it results in an Data bus
error when it gets initialized.

Cc: Michael Buesch <m@bues.ch>
Cc: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rtl8192{ce,cu,de,se}: avoid problems because of possible ERFOFF -> ERFSLEEP transition

In drivers rtl8192ce, rtl8192cu, rtl8192se, and rtl8192de, break
statements would allow ppsc->rfpwr_state to be changed to ERFSLEEP
even though the device is actually in ERFOFF.

Signed-off-by: Philipp Dreimann <philipp@dreimann.net>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Cc: Chaoming Li <chaoming_li@realsil.com.cn>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: fix another race in aggregation start

Emmanuel noticed that when mac80211 stops the queues
for aggregation that can leave a packet pending. This
packet will be given to the driver after the AMPDU
callback, but as a non-aggregated packet which messes
up the sequence number etc.

I also noticed by looking at the code that if packets
are being processed while we clear the WANT_START bit,
they might see it cleared already and queue up on
tid_tx->pending. If the driver then rejects the new
aggregation session we leak the packet.

Fix both of these issues by changing this code to not
stop the queues at all. Instead, let packets queue up
on the tid_tx->pending queue instead of letting them
get to the driver, and add code to recover properly
in case the driver rejects the session.

(The patch looks large because it has to move two
functions to before their new use.)

Cc: stable@vger.kernel.org
Reported-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: fix check for antenna diversity support

fixes a regression on single-stream chips introduced in
commit 43c3528430bd29f5e52438cad7cf7c0c62bf4583
"ath9k: implement .get_antenna and .set_antenna"

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Reported-by: Marek Lindner <lindner_marek@yahoo.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Merge branch 'master' of git://git./linux/kernel/git/padovan/bluetooth

Bluetooth: Correct version check in hci_setup

Check for hci_ver instead of lmp_ver

Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

btusb: fix a memory leak in btusb_send_frame()

This patch fixes the following memory leak reported by kmemleak:

unreferenced object 0xffff880060a53840 (size 192):
  comm "softirq", pid 0, jiffies 4320571771 (age 1406.569s)
  hex dump (first 32 bytes):
    01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffff81138a1c>] create_object+0x187/0x28b
    [<ffffffff814be12e>] kmemleak_alloc+0x73/0x98
    [<ffffffff811289d3>] __kmalloc+0xfc/0x123
    [<ffffffff81386546>] usb_alloc_urb+0x1e/0x48
    [<ffffffffa0130274>] btusb_send_frame+0x86/0x385 [btusb]
    [<ffffffffa02d8230>] hci_send_frame+0xa0/0xa5 [bluetooth]
    [<ffffffffa02d8a4e>] hci_cmd_task+0xa0/0xfb [bluetooth]
    [<ffffffff81058548>] tasklet_action+0x8f/0xef
    [<ffffffff81058a4c>] __do_softirq+0xf4/0x1db
    [<ffffffff81058bb7>] run_ksoftirqd+0x84/0x129
    [<ffffffff8106f1c4>] kthread+0xa0/0xa8
    [<ffffffff814dd144>] kernel_thread_helper+0x4/0x10
    [<ffffffffffffffff>] 0xffffffffffffffff

The problem is that when inc_tx() returns non-zero, we forgot
to call usb_free_urb().

Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: "Gustavo F. Padovan" <padovan@profusion.mobi>
Signed-off-by: WANG Cong <amwang@redhat.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

iwlwifi: change the default behavior of watchdog timer

The current default watchdog timer is enabled, but we are seeing issues on
legacy devices. So change the default setting of watchdog timer to per
device based. But user still can use the "wd_disable" module parameter
to overwrite the system setting

Cc: stable@vger.kernel.org #3.0+
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlwifi: do not re-configure HT40 after associated

The ht40 setting should not change after association unless channel switch

This fix a problem we are seeing which cause uCode assert because driver
sending invalid information and make uCode confuse

Here is the firmware assert message:
kernel: iwlagn 0000:03:00.0: Microcode SW error detected.  Restarting 0x82000000.
kernel: iwlagn 0000:03:00.0: Loaded firmware version: 17.168.5.3 build 42301
kernel: iwlagn 0000:03:00.0: Start IWL Error Log Dump:
kernel: iwlagn 0000:03:00.0: Status: 0x000512E4, count: 6
kernel: iwlagn 0000:03:00.0: 0x00002078 | ADVANCED_SYSASSERT
kernel: iwlagn 0000:03:00.0: 0x00009514 | uPc
kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink1
kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink2
kernel: iwlagn 0000:03:00.0: 0x0000D1F2 | interruptlink1
kernel: iwlagn 0000:03:00.0: 0x00000000 | interruptlink2
kernel: iwlagn 0000:03:00.0: 0x01008035 | data1
kernel: iwlagn 0000:03:00.0: 0x0000C90F | data2
kernel: iwlagn 0000:03:00.0: 0x000005A7 | line
kernel: iwlagn 0000:03:00.0: 0x5080B520 | beacon time
kernel: iwlagn 0000:03:00.0: 0xCC515AE0 | tsf low
kernel: iwlagn 0000:03:00.0: 0x00000003 | tsf hi
kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp1
kernel: iwlagn 0000:03:00.0: 0x29703BF0 | time gp2
kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp3
kernel: iwlagn 0000:03:00.0: 0x000111A8 | uCode version
kernel: iwlagn 0000:03:00.0: 0x000000B0 | hw version
kernel: iwlagn 0000:03:00.0: 0x00480303 | board version
kernel: iwlagn 0000:03:00.0: 0x09E8004E | hcmd
kernel: iwlagn 0000:03:00.0: CSR values:
kernel: iwlagn 0000:03:00.0: (2nd byte of CSR_INT_COALESCING is CSR_INT_PERIODIC_REG)
kernel: iwlagn 0000:03:00.0:        CSR_HW_IF_CONFIG_REG: 0X00480303
kernel: iwlagn 0000:03:00.0:          CSR_INT_COALESCING: 0X0000ff40
kernel: iwlagn 0000:03:00.0:                     CSR_INT: 0X00000000
kernel: iwlagn 0000:03:00.0:                CSR_INT_MASK: 0X00000000
kernel: iwlagn 0000:03:00.0:           CSR_FH_INT_STATUS: 0X00000000
kernel: iwlagn 0000:03:00.0:                 CSR_GPIO_IN: 0X00000030
kernel: iwlagn 0000:03:00.0:                   CSR_RESET: 0X00000000
kernel: iwlagn 0000:03:00.0:                CSR_GP_CNTRL: 0X080403c5
kernel: iwlagn 0000:03:00.0:                  CSR_HW_REV: 0X000000b0
kernel: iwlagn 0000:03:00.0:              CSR_EEPROM_REG: 0X07d60ffd
kernel: iwlagn 0000:03:00.0:               CSR_EEPROM_GP: 0X90000001
kernel: iwlagn 0000:03:00.0:              CSR_OTP_GP_REG: 0X00030001
kernel: iwlagn 0000:03:00.0:                 CSR_GIO_REG: 0X00080044
kernel: iwlagn 0000:03:00.0:            CSR_GP_UCODE_REG: 0X000093bb
kernel: iwlagn 0000:03:00.0:           CSR_GP_DRIVER_REG: 0X00000000
kernel: iwlagn 0000:03:00.0:           CSR_UCODE_DRV_GP1: 0X00000000
kernel: iwlagn 0000:03:00.0:           CSR_UCODE_DRV_GP2: 0X00000000
kernel: iwlagn 0000:03:00.0:                 CSR_LED_REG: 0X00000078
kernel: iwlagn 0000:03:00.0:        CSR_DRAM_INT_TBL_REG: 0X88214dd2
kernel: iwlagn 0000:03:00.0:        CSR_GIO_CHICKEN_BITS: 0X27800200
kernel: iwlagn 0000:03:00.0:             CSR_ANA_PLL_CFG: 0X00000000
kernel: iwlagn 0000:03:00.0:           CSR_HW_REV_WA_REG: 0X0001001a
kernel: iwlagn 0000:03:00.0:        CSR_DBG_HPET_MEM_REG: 0Xffff0010
kernel: iwlagn 0000:03:00.0: FH register values:
kernel: iwlagn 0000:03:00.0:         FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X21316d00
kernel: iwlagn 0000:03:00.0:        FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X021479c0
kernel: iwlagn 0000:03:00.0:                  FH_RSCSR_CHNL0_WPTR: 0X00000060
kernel: iwlagn 0000:03:00.0:         FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80819104
kernel: iwlagn 0000:03:00.0:          FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc
kernel: iwlagn 0000:03:00.0:            FH_MEM_RSSR_RX_STATUS_REG: 0X07030000
kernel: iwlagn 0000:03:00.0:    FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000
kernel: iwlagn 0000:03:00.0:                FH_TSSR_TX_STATUS_REG: 0X07ff0001
kernel: iwlagn 0000:03:00.0:                 FH_TSSR_TX_ERROR_REG: 0X00000000
kernel: iwlagn 0000:03:00.0: Start IWL Event Log Dump: display last 20 entries
kernel: ------------[ cut here ]------------
WARNING: at net/mac80211/util.c:1208 ieee80211_reconfig+0x1f1/0x407()
kernel: Hardware name: 4290W4H
kernel: Pid: 1896, comm: kworker/0:0 Not tainted 3.1.0 #2
kernel: Call Trace:
kernel:  [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
kernel:  [<ffffffff813b8966>] ? ieee80211_reconfig+0x1f1/0x407
kernel:  [<ffffffff8139e8dc>] ? ieee80211_recalc_smps_work+0x32/0x32
kernel:  [<ffffffff8139e95a>] ? ieee80211_restart_work+0x7e/0x87
kernel:  [<ffffffff810472fa>] ? process_one_work+0x1c8/0x2e3
kernel:  [<ffffffff810480c9>] ? worker_thread+0x17a/0x23a
kernel:  [<ffffffff81047f4f>] ? manage_workers.clone.18+0x15b/0x15b
kernel:  [<ffffffff81047f4f>] ? manage_workers.clone.18+0x15b/0x15b
kernel:  [<ffffffff8104ba97>] ? kthread+0x7a/0x82
kernel:  [<ffffffff813d21b4>] ? kernel_thread_helper+0x4/0x10
kernel:  [<ffffffff8104ba1d>] ? kthread_flush_work_fn+0x11/0x11
kernel:  [<ffffffff813d21b0>] ? gs_change+0xb/0xb

Cc: <stable@kernel.org> 3.1+
Reported-by: Udo Steinberg <udo@hypervisor.org>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlagn: fix HW crypto for TX-only keys

Group keys in IBSS or AP mode are not programmed
into the device since we give the key to it with
every TX packet. However, we do need mac80211 to
create the MMIC & PN in all cases. Move the code
around to set the key flags all the time. We set
them even when the key is removed again but that
is obviously harmless.

Cc: stable@vger.kernel.org
Reported-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Revert "mac80211: clear sta.drv_priv on reconfiguration"

This reverts commit f785d83a19bca326f79d127a413e35769afc0105.

This was provoking WARNINGs from the iwlegacy drivers.

Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: fill rate filter for internal scan requests

The rates bitmap for internal scan requests shoud be filled,
otherwise there will be probe requests with zero rates supported.

Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>

cfg80211: amend regulatory NULL dereference fix

Johannes' patch for "cfg80211: fix regulatory NULL dereference"
broke user regulaotry hints and it did not address the fact that
last_request was left populated even if the previous regulatory
hint was stale due to the wiphy disappearing.

Fix user reguluatory hints by only bailing out if for those
regulatory hints where a request_wiphy is expected. The stale last_request
considerations are addressed through the previous fixes on last_request
where we reset the last_request to a static world regdom request upon
reset_regdomains(). In this case though we further enhance the effect
by simply restoring reguluatory settings completely.

Cc: stable@vger.kernel.org
Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

cfg80211: fix race on init and driver registration

There is a theoretical race that if hit will trigger
a crash. The race is between when we issue the first
regulatory hint, regulatory_hint_core(), gets processed
by the workqueue and between when the first device
gets registered to the wireless core. This is not easy
to reproduce but it was easy to do so through the
regulatory simulator I have been working on. This
is a port of the fix I implemented there [1].

[1] https://github.com/mcgrof/regsim/commit/a246ccf81f059cb662eee288aa13100f631e4cc8

Cc: stable@vger.kernel.org
Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: fix race between the AGG SM and the Tx data path

When a packet is supposed to sent be as an a-MPDU, mac80211 sets
IEEE80211_TX_CTL_AMPDU to let the driver know. On the other
hand, mac80211 configures the driver for aggregration with the
ampdu_action callback.
There is race between these two mechanisms since the following
scenario can occur when the BA agreement is torn down:

Tx softIRQ   drv configuration
========== =================

check OPERATIONAL bit
Set the TX_CTL_AMPDU bit in the packet

clear OPERATIONAL bit
stop Tx AGG
Pass Tx packet to the driver.

In that case the driver would get a packet with TX_CTL_AMPDU set
although it has already been notified that the BA session has been
torn down.

To fix this, we need to synchronize all the Qdisc activity after we
cleared the OPERATIONAL bit. After that step, all the following
packets will be buffered until the driver reports it is ready to get
new packets for this RA / TID. This buffering allows not to run into
another race that would send packets with TX_CTL_AMPDU unset while
the driver hasn't been requested to tear down the BA session yet.

This race occurs in practice and iwlwifi complains with a WARN_ON
when it happens.

Cc: stable@kernel.org
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: fix race condition caused by late addBA response

If addBA responses comes in just after addba_resp_timer has
expired mac80211 will still accept it and try to open the
aggregation session. This causes drivers to be confused and
in some cases even crash.

This patch fixes the race condition and makes sure that if
addba_resp_timer has expired addBA response is not longer
accepted and we do not try to open half-closed session.

Cc: stable@vger.kernel.org
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
[some adjustments]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: Revert change that broke AR928X on Acer Ferrari One

Revert a hunk in drivers/net/wireless/ath/ath9k/hw.c introduced by
commit 2577c6e8f2320f1d2f09be122efef5b9118efee4 (ath9k_hw: Add
support for AR946/8x chipsets) that caused a nasty regression to
appear on my Acer Ferrari One (the box locks up entirely at random
times after the wireless has been started without any way to get
debug information out of it).

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rtlwifi: fix lps_lock deadlock

rtl_lps_leave can be called from interrupt context, so we have to
disable interrupts when taking lps_lock.

Below is full lockdep info about deadlock:

[   93.815269] =================================
[   93.815390] [ INFO: inconsistent lock state ]
[   93.815472] 2.6.41.1-3.offch.fc15.x86_64.debug #1
[   93.815556] ---------------------------------
[   93.815635] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[   93.815743] swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
[   93.815832]  (&(&rtlpriv->locks.lps_lock)->rlock){+.?...}, at: [<ffffffffa025dad6>] rtl_lps_leave+0x26/0x103 [rtlwifi]
[   93.815947] {SOFTIRQ-ON-W} state was registered at:
[   93.815947]   [<ffffffff8108e10d>] __lock_acquire+0x369/0xd0c
[   93.815947]   [<ffffffff8108efb3>] lock_acquire+0xf3/0x13e
[   93.815947]   [<ffffffff814e981d>] _raw_spin_lock+0x45/0x79
[   93.815947]   [<ffffffffa025de34>] rtl_swlps_rf_awake+0x5a/0x76 [rtlwifi]
[   93.815947]   [<ffffffffa025aec0>] rtl_op_config+0x12a/0x32a [rtlwifi]
[   93.815947]   [<ffffffffa01d614b>] ieee80211_hw_config+0x124/0x129 [mac80211]
[   93.815947]   [<ffffffffa01e0af3>] ieee80211_dynamic_ps_disable_work+0x32/0x47 [mac80211]
[   93.815947]   [<ffffffff81075aa5>] process_one_work+0x205/0x3e7
[   93.815947]   [<ffffffff81076753>] worker_thread+0xda/0x15d
[   93.815947]   [<ffffffff8107a119>] kthread+0xa8/0xb0
[   93.815947]   [<ffffffff814f3184>] kernel_thread_helper+0x4/0x10
[   93.815947] irq event stamp: 547822
[   93.815947] hardirqs last  enabled at (547822): [<ffffffff814ea1a7>] _raw_spin_unlock_irqrestore+0x45/0x61
[   93.815947] hardirqs last disabled at (547821): [<ffffffff814e9987>] _raw_spin_lock_irqsave+0x22/0x8e
[   93.815947] softirqs last  enabled at (547790): [<ffffffff810623ed>] _local_bh_enable+0x13/0x15
[   93.815947] softirqs last disabled at (547791): [<ffffffff814f327c>] call_softirq+0x1c/0x30
[   93.815947]
[   93.815947] other info that might help us debug this:
[   93.815947]  Possible unsafe locking scenario:
[   93.815947]
[   93.815947]        CPU0
[   93.815947]        ----
[   93.815947]   lock(&(&rtlpriv->locks.lps_lock)->rlock);
[   93.815947]   <Interrupt>
[   93.815947]     lock(&(&rtlpriv->locks.lps_lock)->rlock);
[   93.815947]
[   93.815947]  *** DEADLOCK ***
[   93.815947]
[   93.815947] no locks held by swapper/0.
[   93.815947]
[   93.815947] stack backtrace:
[   93.815947] Pid: 0, comm: swapper Not tainted 2.6.41.1-3.offch.fc15.x86_64.debug #1
[   93.815947] Call Trace:
[   93.815947]  <IRQ>  [<ffffffff814dfd00>] print_usage_bug+0x1e7/0x1f8
[   93.815947]  [<ffffffff8101a849>] ? save_stack_trace+0x2c/0x49
[   93.815947]  [<ffffffff8108d55c>] ? print_irq_inversion_bug.part.18+0x1a0/0x1a0
[   93.815947]  [<ffffffff8108dc8a>] mark_lock+0x106/0x220
[   93.815947]  [<ffffffff8108e099>] __lock_acquire+0x2f5/0xd0c
[   93.815947]  [<ffffffff810152af>] ? native_sched_clock+0x34/0x36
[   93.830125]  [<ffffffff810152ba>] ? sched_clock+0x9/0xd
[   93.830125]  [<ffffffff81080181>] ? sched_clock_local+0x12/0x75
[   93.830125]  [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi]
[   93.830125]  [<ffffffff8108efb3>] lock_acquire+0xf3/0x13e
[   93.830125]  [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi]
[   93.830125]  [<ffffffff814e981d>] _raw_spin_lock+0x45/0x79
[   93.830125]  [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi]
[   93.830125]  [<ffffffff81422467>] ? skb_dequeue+0x62/0x6d
[   93.830125]  [<ffffffffa025dad6>] rtl_lps_leave+0x26/0x103 [rtlwifi]
[   93.830125]  [<ffffffffa025f677>] _rtl_pci_ips_leave_tasklet+0xe/0x10 [rtlwifi]
[   93.830125]  [<ffffffff8106281f>] tasklet_action+0x8d/0xee
[   93.830125]  [<ffffffff810629ce>] __do_softirq+0x112/0x25a
[   93.830125]  [<ffffffff814f327c>] call_softirq+0x1c/0x30
[   93.830125]  [<ffffffff81010bf6>] do_softirq+0x4b/0xa1
[   93.830125]  [<ffffffff81062d7d>] irq_exit+0x5d/0xcf
[   93.830125]  [<ffffffff814f3b7e>] do_IRQ+0x8e/0xa5
[   93.830125]  [<ffffffff814ea533>] common_interrupt+0x73/0x73
[   93.830125]  <EOI>  [<ffffffff8108b825>] ? trace_hardirqs_off+0xd/0xf
[   93.830125]  [<ffffffff812bb6d5>] ? intel_idle+0xe5/0x10c
[   93.830125]  [<ffffffff812bb6d1>] ? intel_idle+0xe1/0x10c
[   93.830125]  [<ffffffff813f8d5e>] cpuidle_idle_call+0x11c/0x1fe
[   93.830125]  [<ffffffff8100e2ef>] cpu_idle+0xab/0x101
[   93.830125]  [<ffffffff814c6373>] rest_init+0xd7/0xde
[   93.830125]  [<ffffffff814c629c>] ? csum_partial_copy_generic+0x16c/0x16c
[   93.830125]  [<ffffffff81d4bbb0>] start_kernel+0x3dd/0x3ea
[   93.830125]  [<ffffffff81d4b2c4>] x86_64_start_reservations+0xaf/0xb3
[   93.830125]  [<ffffffff81d4b140>] ? early_idt_handlers+0x140/0x140
[   93.830125]  [<ffffffff81d4b3ca>] x86_64_start_kernel+0x102/0x111

Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=755154

Reported-by: vjain02@students.poly.edu
Reported-and-tested-by: Oliver Paukstadt <pstadt@sourcentral.org>
Cc: stable@vger.kernel.org
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: don't stop a single aggregation session twice

Nikolay noticed (by code review) that mac80211 can
attempt to stop an aggregation session while it is
already being stopped. So to fix it, check whether
stop is already being done and bail out if so.

Also move setting the STOPPING state into the lock
so things are properly atomic.

Cc: stable@vger.kernel.org
Reported-by: Nikolay Martynov <mar.kolya@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

nl80211: fix MAC address validation

MAC addresses have a fixed length. The current
policy allows passing < ETH_ALEN bytes, which
might result in reading beyond the buffer.

Cc: stable@vger.kernel.org
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Revert "rt2800pci: handle spurious interrupts"

This reverts commit 4ba7d9997869d25bd223dea7536fc1ce9fab3b3b.

The original patch was a misguided attempt to improve performance on
some hardware that is apparently prone to spurious interrupt generation.

Signed-off-by: John W. Linville <linville@tuxdriver.com>

Revert "rt2x00: handle spurious pci interrupts"

This reverts commit 23085d5796561625db4143a671f1de081f66ef08.

The original patch was a misguided attempt to improve performance on
some hardware that is apparently prone to spurious interrupt generation.

Signed-off-by: John W. Linville <linville@tuxdriver.com>

prism54: potential memory corruption in prism54_get_essid()

"dwrq->length" is the capped version of "essid->length".

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

cfg80211: fix regulatory NULL dereference

By the time userspace returns with a response to
the regulatory domain request, the wiphy causing
the request might have gone away. If this is so,
reject the update but mark the request as having
been processed anyway.

Cc: Luis R. Rodriguez <lrodriguez@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: Fix endian bug in radiotap header generation

I intoduced this bug in commit a2fe81667410723d941a688e1958a49d67ca3346
"mac80211: Build TX radiotap header dynamically"

Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: Fix AMSDU rate printout in debugfs.

It was flipped.  See section 7.3.2.56 of the 802.11n
spec for details.

Signed-off-by: Ben Greear <greearb@candelatech.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Bluetooth: bnep: Fix module reference

We cannot call module_put(THIS_MODULE) if this is our last reference. Otherwise,
this call may cleanup our module before it returns.

Gladly, the kthread API provides a simple wrapper for us. So lets use
module_put_and_exit() to avoid a race condition with the module cleanup code.

Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: cmtp: Fix module reference

We cannot call module_put(THIS_MODULE) if this is our last reference. Otherwise,
this call may cleanup our module before it returns.

Gladly, the kthread API provides a simple wrapper for us. So lets use
module_put_and_exit() to avoid a race condition with the module cleanup code.

Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: btmrvl: support Marvell Bluetooth device SD8797

The SD8797 firmware image is shared with mwifiex driver.
Whoever gets loaded first will be responsible for firmware
downloading.

Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Frank Huang <frankh@marvell.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

p54spi: Fix workqueue deadlock

priv->work must not be synced while priv->mutex is locked, because
the mutex is taken in the work handler.
Move cancel_work_sync down to after the device shutdown code.
This is safe, because the work handler checks fw_state and bails out
early in case of a race.

Signed-off-by: Michael Buesch <m@bues.ch>
Cc: <stable@vger.kernel.org>
Acked-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

p54spi: Add missing spin_lock_init

The tx_lock is not initialized properly. Add spin_lock_init().

Signed-off-by: Michael Buesch <m@bues.ch>
Cc: <stable@vger.kernel.org>
Acked-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rt2x00: Fix efuse EEPROM reading on PPC32.

Fix __le32 to __le16 conversion of the first word of an 8-word block
of EEPROM read via the efuse method.

Reported-and-tested-by: Ingvar Hagelund <ingvar@redpill-linpro.com>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
CC: <stable@vger.kernel.org>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rt2x00: handle spurious pci interrupts

We have documented case of very bad performance issue on rt2800pci
device, because it generate spurious interrupt, what cause irq line
is disabled: https://bugzilla.redhat.com/show_bug.cgi?id=658451

We already address that problem in separate patch by returning
IRQ_HANDLED from interrupt handler. We think similar fix is needed for
other rt2x00 PCI devices, because users report performance problems on
these devices too.

Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rt2800pci: handle spurious interrupts

Some devices may generate spurious interrupts, we have to handle them
otherwise interrupt line will be disabled with below message and driver
will not work:

[ 2052.114334] irq 17: nobody cared (try booting with the "irqpoll" option)
[ 2052.114339] Pid: 0, comm: swapper Tainted: P           2.6.35.6-48.fc14.x86_64 #1
[ 2052.114341] Call Trace:
[ 2052.114342]  <IRQ>  [<ffffffff810a6e2b>] __report_bad_irq.clone.1+0x3d/0x8b
[ 2052.114349]  [<ffffffff810a6f93>] note_interrupt+0x11a/0x17f
[ 2052.114352]  [<ffffffff810a7a73>] handle_fasteoi_irq+0xa8/0xce
[ 2052.114355]  [<ffffffff8100c2ea>] handle_irq+0x88/0x90
[ 2052.114357]  [<ffffffff8146f034>] do_IRQ+0x5c/0xb4
[ 2052.114360]  [<ffffffff81469593>] ret_from_intr+0x0/0x11
[ 2052.114361]  <EOI>  [<ffffffff8102b7f9>] ? native_safe_halt+0xb/0xd
[ 2052.114366]  [<ffffffff81010f03>] ? need_resched+0x23/0x2d
[ 2052.114367]  [<ffffffff8101102a>] default_idle+0x34/0x4f
[ 2052.114370]  [<ffffffff81008325>] cpu_idle+0xaa/0xcc
[ 2052.114373]  [<ffffffff81461f2a>] start_secondary+0x24d/0x28e
[ 2052.114374] handlers:
[ 2052.114375] [<ffffffff81332944>] (usb_hcd_irq+0x0/0x7c)
[ 2052.114378] [<ffffffffa00697da>] (rt2800pci_interrupt+0x0/0x18d [rt2800pci])
[ 2052.114384] Disabling IRQ #17

Resolve:
https://bugzilla.redhat.com/show_bug.cgi?id=658451

Reported-and-tested-by: Amir Hedayaty <hedayaty@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Net, libertas: Resolve memory leak in if_spi_host_to_card()

If we hit the default case in the switch in if_spi_host_to_card() we'll leak
the memory we allocated for 'packet'. This patch resolves the leak by freeing
the allocated memory in that case.

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Dan Williams <dcbw@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rt2x00: Fix sleep-while-atomic bug in powersaving code.

The generic powersaving code that determines after reception of a frame
whether the device should go back to sleep or whether is could stay
awake was calling rt2x00lib_config directly from RX tasklet context.
On a number of the devices this call can actually sleep, due to having
to confirm that the sleeping commands have been executed successfully.

Fix this by moving the call to rt2x00lib_config to a workqueue call.

This fixes bug https://bugzilla.redhat.com/show_bug.cgi?id=731672

Tested-by: Tomas Trnka <tomastrnka@gmx.com>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Cc: <stable@vger.kernel.org>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rt2x00: Add USB device ID of Buffalo WLI-UC-GNHP.

This is reported to be an RT3070 based device.

Reported-by: Teika Kazura <teika@lavabit.com>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mwifiex: fix association issue with AP configured in hidden SSID mode

Firmware expects 'max_ssid_length' field in
'struct mwifiex_ie_types_wildcard_ssid_params' to be '0' for
performing SSID specific scan. Currently driver updates it with
an actual SSID length. Hence UUT is not able to find the AP
configured in hidden SSID mode in scan results and association
fails.

max_ssid_length is filled with '0' to fix the issue.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlwifi: avoid a panic when unloading the module with RF Kill

When HW RF kill switch is set to kill the radio, our NIC issues an
interrupt after we stop the APM module. When we unload the module,
the driver disables and cleans the interrupts before stopping the
APM. So we have a real interrupt (inta not zero) pending.
When this interrupts pops up the tasklet has already been killed
and we crash.

Here is a logical description of the flow:

disable and clean interrupts
synchronize interrupts
kill the tasklet

stop the APM <<== creates an RF kill interrupt

free_irq <<== somehow our ISR is called here and we crash

Here is the panic message:

[  201.313636] BUG: unable to handle kernel paging request at ffff8800911b7150
[  201.314541] IP: [<ffffffff8106d652>] tasklet_action+0x62/0x130
[  201.315149] PGD 1c06063 PUD db37f067 PMD db408067 PTE 80000000911b7160
[  201.316456] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
[  201.317324] CPU 1
[  201.317495] Modules linked in: arc4 iwlwifi(-) mac80211 cfg80211 netconsole configfs binfmt_misc i915 drm_kms_helper drm uvcvideo i2c_algo_bit videodev dell_laptop dcdbas intel_agp dell_wmi intel_ips psmouse intel_gtt v4l2_compat_ioctl32 asix usbnet mii serio_raw video sparse_keymap firewire_ohci sdhci_pci sdhci firewire_core e1000e crc_itu_t [last unloaded: configfs]
[  201.323839]
[  201.324015] Pid: 2061, comm: modprobe Not tainted 3.1.0-rc9-wl #4 Dell Inc. Latitude E6410/0667CC
[  201.324736] RIP: 0010:[<ffffffff8106d652>]  [<ffffffff8106d652>] tasklet_action+0x62/0x130
[  201.325128] RSP: 0018:ffff88011bc43ea0  EFLAGS: 00010286
[  201.325338] RAX: ffff88008ae70000 RBX: ffff8800911b7150 RCX: ffff88008ae70028
[  201.325555] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88008ae70000
[  201.325775] RBP: ffff88011bc43ec0 R08: 0000000000000000 R09: 0000000000000000
[  201.325994] R10: 0000000000000002 R11: 0000000000000001 R12: 0000000000000001
[  201.326212] R13: 0000000000000006 R14: 0000000000000100 R15: ffff88008e259fd8
[  201.326431] FS:  00007f4b90ea9700(0000) GS:ffff88011bc40000(0000) knlGS:0000000000000000
[  201.326657] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  201.326864] CR2: ffff8800911b7150 CR3: 000000008fd6d000 CR4: 00000000000006e0
[  201.327083] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  201.327302] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  201.327521] Process modprobe (pid: 2061, threadinfo ffff88008e258000, task ffff88008ae70000)
[  201.327747] Stack:
[  201.330494]  0000000000000046 0000000000000030 0000000000000001 0000000000000006
[  201.333870]  ffff88011bc43f30 ffffffff8106cd8a ffffffff811e1016 ffff88011bc43f08
[  201.337186]  0000000100000046 ffff88008e259fd8 0000000a10be2160 0000000000000006
[  201.340458] Call Trace:
[  201.342994]  <IRQ>
[  201.345656]  [<ffffffff8106cd8a>] __do_softirq+0xca/0x250
[  201.348185]  [<ffffffff811e1016>] ? pde_put+0x76/0x90
[  201.350730]  [<ffffffff8131aeae>] ? do_raw_spin_unlock+0x5e/0xb0
[  201.353261]  [<ffffffff811e1016>] ? pde_put+0x76/0x90
[  201.355776]  [<ffffffff8163ccfc>] call_softirq+0x1c/0x30
[  201.358287]  [<ffffffff8101531d>] do_softirq+0x9d/0xd0
[  201.360823]  [<ffffffff8106cb05>] irq_exit+0xd5/0xf0
[  201.363330]  [<ffffffff8163d5d6>] do_IRQ+0x66/0xe0
[  201.365819]  [<ffffffff81632673>] common_interrupt+0x73/0x73
[  201.368257]  <EOI>

Cc: <stable@kernel.org> 3.1+
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: fix race between connection monitor & suspend

When the connection monitor timer fires right before
suspend, the following will happen:
 timer fires -> monitor_work gets queued
 suspend calls ieee80211_sta_quiesce
 ieee80211_sta_quiesce:
  - deletes timer
  - cancels monitor_work synchronously, running it
  [note wrong order of these steps]
 monitor_work runs, re-arming the timer
 later, timer fires while system should be quiesced

This causes a warning:

WARNING: at net/mac80211/util.c:540 ieee80211_can_queue_work+0x35/0x40 [mac80211]()

but is otherwise harmless. I'm not completely sure
this is the scenario Thomas stumbled across, but it
is the only way I can right now see the warning in
a scenario like the one he reported.

Reported-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

wireless: libertas: fix unaligned le64 accesses

use get_unaligned_le64() to get timestamp

Signed-off-by: Steven Miao <realmz6@gmail.com>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

cfg80211: fix bug on regulatory core exit on access to last_request

Commit 4d9d88d1 by Scott James Remnant <keybuk@google.com> added
the .uevent() callback for the regulatory device used during
the platform device registration. The change was done to account
for queuing up udev change requests through udevadm triggers.
The change also meant that upon regulatory core exit we will now
send a uevent() but the uevent() callback, reg_device_uevent(),
also accessed last_request. Right before commiting device suicide
we free'd last_request but never set it to NULL so
platform_device_unregister() would lead to bogus kernel paging
request. Fix this and also simply supress uevents right before
we commit suicide as they are pointless.

This fix is required for kernels >= v2.6.39

$ git describe --contains 4d9d88d1
v2.6.39-rc1~468^2~25^2^2~21

The impact of not having this present is that a bogus paging
access may occur (only read) upon cfg80211 unload time. You
may also get this BUG complaint below. Although Johannes
could not reproduce the issue this fix is theoretically correct.

mac80211_hwsim: unregister radios
mac80211_hwsim: closing netlink
BUG: unable to handle kernel paging request at ffff88001a06b5ab
IP: [<ffffffffa030df9a>] reg_device_uevent+0x1a/0x50 [cfg80211]
PGD 1836063 PUD 183a063 PMD 1ffcb067 PTE 1a06b160
Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
CPU 0
Modules linked in: cfg80211(-) [last unloaded: mac80211]

Pid: 2279, comm: rmmod Tainted: G        W   3.1.0-wl+ #663 Bochs Bochs
RIP: 0010:[<ffffffffa030df9a>]  [<ffffffffa030df9a>] reg_device_uevent+0x1a/0x50 [cfg80211]
RSP: 0000:ffff88001c5f9d58  EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff88001d2eda88 RCX: ffff88001c7468fc
RDX: ffff88001a06b5a0 RSI: ffff88001c7467b0 RDI: ffff88001c7467b0
RBP: ffff88001c5f9d58 R08: 000000000000ffff R09: 000000000000ffff
R10: 0000000000000000 R11: 0000000000000001 R12: ffff88001c7467b0
R13: ffff88001d2eda78 R14: ffffffff8164a840 R15: 0000000000000001
FS:  00007f8a91d8a6e0(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffff88001a06b5ab CR3: 000000001c62e000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process rmmod (pid: 2279, threadinfo ffff88001c5f8000, task ffff88000023c780)
Stack:
 ffff88001c5f9d98 ffffffff812ff7e5 ffffffff8176ab3d ffff88001c7468c2
 000000000000ffff ffff88001d2eda88 ffff88001c7467b0 ffff880000114820
 ffff88001c5f9e38 ffffffff81241dc7 ffff88001c5f9db8 ffffffff81040189
Call Trace:
 [<ffffffff812ff7e5>] dev_uevent+0xc5/0x170
 [<ffffffff81241dc7>] kobject_uevent_env+0x1f7/0x490
 [<ffffffff81040189>] ? sub_preempt_count+0x29/0x60
 [<ffffffff814cab1a>] ? _raw_spin_unlock_irqrestore+0x4a/0x90
 [<ffffffff81305307>] ? devres_release_all+0x27/0x60
 [<ffffffff8124206b>] kobject_uevent+0xb/0x10
 [<ffffffff812fee27>] device_del+0x157/0x1b0
 [<ffffffff8130377d>] platform_device_del+0x1d/0x90
 [<ffffffff81303b76>] platform_device_unregister+0x16/0x30
 [<ffffffffa030fffd>] regulatory_exit+0x5d/0x180 [cfg80211]
 [<ffffffffa032bec3>] cfg80211_exit+0x2b/0x45 [cfg80211]
 [<ffffffff8109a84c>] sys_delete_module+0x16c/0x220
 [<ffffffff8108a23e>] ? trace_hardirqs_on_caller+0x7e/0x120
 [<ffffffff814cba02>] system_call_fastpath+0x16/0x1b
Code: <all your base are belong to me>
RIP  [<ffffffffa030df9a>] reg_device_uevent+0x1a/0x50 [cfg80211]
 RSP <ffff88001c5f9d58>
CR2: ffff88001a06b5ab
---[ end trace 147c5099a411e8c0 ]---

Reported-by: Johannes Berg <johannes@sipsolutions.net>
Cc: Scott James Remnant <keybuk@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: fix bug in ieee80211_build_probe_req

ieee80211_probereq_get() can return NULL in
which case we should clean up & return NULL
in ieee80211_build_probe_req() as well.

Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: fix NULL dereference in radiotap code

When receiving failed PLCP frames is enabled, there
won't be a rate pointer when we add the radiotap
header and thus the kernel will crash. Fix this by
not assuming the rate pointer is always valid. It's
still always valid for frames that have good PLCP
though, and that is checked & enforced.

This was broken by my
commit fc88518916793af8ad6a02e05ff254d95c36d875
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Jul 30 13:23:12 2010 +0200

    mac80211: don't check rates on PLCP error frames

where I removed the check in this case but didn't
take into account that the rate info would be used.

Reported-by: Xiaokang Qin <xiaokang.qin@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

wl12xx: fix wl12xx_scan_sched_scan_ssid_list() check that all given ssids are in filters

A minor fix for the check that verifies that all given SSIDs (in req) exist
in the filters (the match sets)

Signed-off-by: Eyal Shapira <eyal@wizery.com>
Acked-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath: Fix NULL ptr dereference in ath_reg_apply_world_flags

This happens with devices using a regulatory domain 0x68 that are only
5Ghz capable because ath_reg_apply_active_scan_flags assumes that we
always have a 2,4Ghz band.

CPU 0 Unable to handle kernel paging request at virtual address 00000000, epc == 82cd838c, ra == 82cd8384
Oops[#1]:
Cpu 0
$ 0 : 00000000 00000061 00000003 00000024
$ 4 : 00000003 000016c1 82f900ac 00000024
$ 8 : 00000000 82cda304 0058bad8 00000005
$12 : 005908f8 001e8481 00000003 1dcd6500
$16 : 00000002 00000000 82c700c0 82c700c0
$20 : 82d415e4 82c70d64 82c70200 82c715bc
$24 : 00000000 11e1a300
$28 : 82ce2000 82ce3c70 82c715a8 82cd8384
Hi : 00000000
Lo : 0000001e
epc : 82cd838c ath_reg_apply_world_flags+0x78/0x17c [ath]
Not tainted
ra : 82cd8384 ath_reg_apply_world_flags+0x70/0x17c [ath]
Status: 1000d403 KERNEL EXL IE
Cause : 80800008
BadVA : 00000000
PrId : 00019374 (MIPS 24Kc)
Modules linked in: ath9k(+) ath9k_common ath9k_hw ath mac80211 cfg80211
compat_firmware_class compat arc4 aes_generic deflate ecb cbc
leds_gpio button_hotplug gpio_buttons input_polldev ie
Process insmod (pid: 464, threadinfo=82ce2000, task=838b31d8, tls=00000000)
Stack : 00000000 00000002 82f900ac 82c700c0 82d415e4 82c70d64 00000000 00000068
82f900ac 82cd88f4 82c700c0 82cda304 00000001 000020f0 82f90000 82c70d40
00000002 82f90000 82f900ac 82d4207c 82d518a0 00000002 7fee6118 8017c0d8
00000008 8397ba00 82c70d40 00000000 82c70200 83813000 83813058 b0010000
82d518a0 00000002 7fee6118 82d4b8c8 83445cc0 80120dc0 83804000 800eeda0
...
Call Trace:
[<82cd838c>] ath_reg_apply_world_flags+0x78/0x17c [ath]
[<82cd88f4>] ath_regd_init+0x464/0x488 [ath]
[<82d4207c>] ath9k_init_device+0x6a4/0x6b4 [ath9k]
[<82d4b8c8>] ath_pci_probe+0x27c/0x358 [ath9k]
[<80181de0>] pci_device_probe+0x64/0xa4
[<8019e874>] driver_probe_device+0xb8/0x190
[<8019e9b8>] __driver_attach+0x6c/0xa4
[<8019dfc0>] bus_for_each_dev+0x60/0xb0
[<8019d744>] bus_add_driver+0xc4/0x25c
[<8019ed6c>] driver_register+0xe0/0x198
[<8018206c>] __pci_register_driver+0x50/0xe0
[<82dd0010>] ath9k_init+0x10/0x54 [ath9k]
[<8006b4a0>] do_one_initcall+0x68/0x1ec
[<800a901c>] sys_init_module+0xec/0x23c
[<80062544>] stack_done+0x20/0x3c

Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

cfg80211: fix missing kernel-doc

Two new struct members were not documented, fix that.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Merge branch 'master' of git://git./linux/kernel/git/padovan/bluetooth

Bluetooth: Add support for Broadcom BCM20702A0

Since this device declares itself as vendor specific, must add
a new entry to device ID table to support it.

usb-device output of this device:

T:  Bus=01 Lev=02 Prnt=02 Port=03 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=413c ProdID=8197 Rev=01.12
S:  Manufacturer=Broadcom Corp
S:  Product=BCM20702A0
S:  SerialNumber=D0DF9AA9C9F1
C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

Signed-off-by: Wen-chien Jesse Sung <jesse.sung@canonical.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: Use miliseconds for L2CAP channel timeouts

Timers set by __set_chan_timer() should use miliseconds instead of
jiffies. Commit 942ecc9c4643db5ce071562e0a23f99464d6b461 updated
l2cap_set_timer() so it expects timeout to be specified in msecs
instead of jiffies. This makes timeouts unreliable when CONFIG_HZ
is not set to 1000.

Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: Revert: Fix L2CAP connection establishment

This reverts commit 330605423ca6eafafb8dcc27502bce1c585d1b06.
The commit introduces regression when two 2.1 devices attempt
establish rfcomm channel. Such connection is refused since there's
a security block issue on l2cap. It means the link is unencrypted.

2011-09-16 18:08:46.567616 < ACL data: handle 1 flags 0x00 dlen 24
    0000: 14 00 40 00 06 00 02 00  0f 35 03 19 12 00 ff ff
..@......5....˙˙
    0010: 35 05 0a 00 00 ff ff 00                           5....˙˙.
2011-09-16 18:08:46.572377 > HCI Event: Number of Completed Packets
(0x13) plen 5
    handle 1 packets 1
2011-09-16 18:08:46.577931 > ACL data: handle 1 flags 0x02 dlen 88
    L2CAP(d): cid 0x0040 len 84 [psm 0]
      0000: 07 00 02 00 4f 00 4c 35  4a 35 48 09 00 00 0a 00
....O.L5J5H.....
      0010: 01 00 00 09 00 01 35 03  19 12 00 09 00 05 35 03
......5.......5.
      0020: 19 10 02 09 00 09 35 08  35 06 19 12 00 09 01 02
......5.5.......
      0030: 09 02 00 09 01 02 09 02  01 09 00 0a 09 02 02 09
................
      0040: 00 00 09 02 03 09 00 00  09 02 04 28 01 09 02 05
...........(....
      0050: 09 00 02 00                                       ....
2011-09-16 18:08:46.626057 < HCI Command: Authentication Requested
(0x01|0x0011) plen 2
    handle 1
2011-09-16 18:08:46.627614 > HCI Event: Command Status (0x0f) plen 4
    Authentication Requested (0x01|0x0011) status 0x00 ncmd 1
2011-09-16 18:08:46.627675 > HCI Event: Link Key Request (0x17) plen 6
    bdaddr 00:00:F2:6A:29:69
2011-09-16 18:08:46.634999 < HCI Command: Link Key Request Reply
(0x01|0x000b) plen 22
    bdaddr 00:00:F2:6A:29:69 key 58CD393179FC902E5E8F512A855EE532
2011-09-16 18:08:46.683278 > HCI Event: Command Complete (0x0e) plen 10
    Link Key Request Reply (0x01|0x000b) ncmd 1
    status 0x00 bdaddr 00:00:F2:6A:29:69
2011-09-16 18:08:46.764729 > HCI Event: Auth Complete (0x06) plen 3
    status 0x00 handle 1
2011-09-16 18:08:46.764821 < ACL data: handle 1 flags 0x00 dlen 12
    0000: 08 00 01 00 02 05 04 00  03 00 41 00              ..........A.
2011-09-16 18:08:46.764851 > HCI Event: Command Status (0x0f) plen 4
    Unknown (0x00|0x0000) status 0x00 ncmd 2
2011-09-16 18:08:46.768117 > HCI Event: Number of Completed Packets
(0x13) plen 5
    handle 1 packets 1
2011-09-16 18:08:46.770894 > ACL data: handle 1 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0000 scid 0x0041 result 3 status 0
      Connection refused - security block
2011-09-16 18:08:49.000691 < ACL data: handle 1 flags 0x00 dlen 12
    0000: 08 00 01 00 06 06 04 00  40 00 40 00              ........@.@.
2011-09-16 18:08:49.015675 > HCI Event: Number of Completed Packets
(0x13) plen 5
    handle 1 packets 1
2011-09-16 18:08:49.016927 > ACL data: handle 1 flags 0x02 dlen 12
    L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040
2011-09-16 18:08:51.009480 < HCI Command: Disconnect (0x01|0x0006) plen
3
    handle 1 reason 0x13
    Reason: Remote User Terminated Connection
2011-09-16 18:08:51.011525 > HCI Event: Command Status (0x0f) plen 4
    Disconnect (0x01|0x0006) status 0x00 ncmd 1
2011-09-16 18:08:51.123494 > HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 1 reason 0x16
    Reason: Connection Terminated by Local Host

Signed-off-by: Arek Lichwa <arkadiusz.lichwa@tieto.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

mac80211: uAPSD - fix IEEE80211_FCTL_MOREDATA bit setting

Set IEEE80211_FCTL_MOREDATA bit also in case we have buffered
frames (more than one) only for one AC.

Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

net, wireless, mwifiex: Fix mem leak in mwifiex_update_curr_bss_params()

If kmemdup() fails we leak the memory allocated to bss_desc.
This patch fixes the leak.
I also removed the pointless default assignment of 'NULL' to 'bss_desc'
while I was there anyway.

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

cfg80211: fix cmp_ies

When comparing two items by IE, the sort order
wasn't stable, which could lead to issues in the
rbtree. Make it stable by making a missing IE
sort before a present IE.

Also sort by length first if it differs and then
by contents.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

cfg80211: allow setting TXQ parameters only in AP mode

In other modes the parameters should not be set.
Right now, mac80211 will set them, even if the
user asked for setting them on VLANs which the
driver doesn't know about, causing all kinds of
trouble.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

nl80211: fix HT capability attribute validation

Since the NL80211_ATTR_HT_CAPABILITY attribute is
used as a struct, it needs a minimum, not maximum
length. Enforce that properly. Not doing so could
potentially lead to reading after the buffer.

Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: use min rate as basic rate for buggy APs

Some buggy APs (and even P2P_GO) don't advertise their
basic rates in the association response.

In such case, use the min supported rate as the
basic rate.

Reported-by: Pontus Fuchs <pontus.fuchs@gmail.com>
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

brcm80211: smac: eliminate a null pointer dereference in dma.c

Though it's unlikely, di may be null, so we can't dereference
di->dma.dmactrlflags until we've checked it.

Move this de-reference after the check, and adjust the error
message to not require de-referencing di.

This is based upon Julia's original patch:
<1319846297-2985-2-git-send-email-julia@diku.dk>

Reported-by: Julia Lawall <julia@diku.dk>
Acked-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Julian Calaby <julian.calaby@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

b43: HT-PHY: report signal to mac80211

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

b43: fill ctl1 word on all newer PHYs, fix PHY errors

This fixes PHY transmission errors reported on some LP-PHY and HT-PHY
cards. For LP-PHY they were quite rare and not really noticable. On
HT-PHY they were critical, OFDM rates were not available at all.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: warn only once about not finding a rate

The warning really shouldn't happen, but until we
find the reason why it does don't spew it all the
time, just once is enough to know we've hit it.

Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlwifi: don't perform "echo test" when cmd queue stuck

Perform "echo test" when cmd queue stuck detected, somethime it will cause
calltrace. I am not sure how to fix it yet, just remove the action now until
find a better way to handle it.

Reported-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

b43: Remove unneeded message

The driver can spam the logs with "RX: Packet dropped" messages. These drops
originate from 1. a correpted PLCP, 2. decryption errors, and 3. packet
size underruns. Condition #3 logs a separate message, thus no dropped message
is needed.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: disable powersave for broken APs

Only AID values 1-2007 are valid, but some APs have been
found to send random bogus values, in the reported case an
AP that was sending the AID field value 0xffff, an AID of
0x3fff (16383).

There isn't much we can do but disable powersave since
there's no way it can work properly in this case.

Cc: stable@vger.kernel.org
Reported-by: Bill C Riemers <briemers@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlwifi: allow pci_enable_msi fail

Continue the init process even fail to enable msi

out_iounmap is no longer used, remove it

Reported-by: werner <w.landgraf@ru.ru>
Tested-by: werner <w.landgraf@ru.ru>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

libertas: ensure we clean up a scan request properly

Commit 2e30168b ("libertas: terminate scan when stopping interface")
adds cleanup code to lbs_eth_stop to call cfg80211_scan_done if there's
an outstanding cfg80211_scan_request.  However, it assumes that the
scan request was allocated via the cfg80211 stack.  Libertas has
its own internal allocation method, kept track of with
priv->internal_scan.  This doesn't set scan_req->wiphy, amongst other
things, which results in hitting a BUG() when we call cfg80211_scan_done
on the request.

This provides a function to take care of the low-level scan_req cleanup
details.  We simply call that to deal with finishing up scan requests.

The bug we were hitting was:

[  964.321495] kernel BUG at net/wireless/core.h:87!
[  964.329970] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[  964.341963] pgd = dcf80000
...
[  964.849998] 9fe0: 00000000 beb417b8 4018e280 401e822c 60000010 00000004 00000000 00000000
[  964.865007] [<c003104c>] (__bug+0x1c/0x28) from [<c0384ffc>] (cfg80211_scan_done+0x54/0x6c)
[  964.895324] [<c0384ffc>] (cfg80211_scan_done+0x54/0x6c) from [<bf028bac>] (lbs_eth_stop+0x10c/0x188 [libertas])
[  964.895324] [<bf028bac>] (lbs_eth_stop+0x10c/0x188 [libertas]) from [<c03002a0>] (__dev_close_many+0x94/0xc4)
[  964.918995] [<c03002a0>] (__dev_close_many+0x94/0xc4) from [<c030037c>] (dev_close_many+0x78/0xe0)

Signed-off-by: Andres Salomon <dilinger@queued.net>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: Fix noise floor calibration timeout on fast channel change

During the fast channel change noise floor values are being loaded
twice at init_cal and after channel_change. The commit "ath9k_hw:
Improve fast channel change for AR9003 chips" overlooked it that
caused failure to load nf while doing bgscan. This patch performs noise
floor calibration after the fast and full reset.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: Update AR9485 initvals to fix system hang issue

This patch fixes system hang when resuming from S3 state
and lower rate sens failure issue.

Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: Fix TDLS support validation in add_station handler

We need to verify whether the command is successful before allocating
the station entry to avoid extra processing. This also fixes a memory
leak on the error path.

Signed-off-by: Jouni Malinen <j@w1.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

carl9170: fix AMPDU TX_CTL_REQ_TX_STATUS handling

Previously the driver did not care if TX_CTL_REQ_TX_STATUS
was set on aggregated frames or not and it would silently
drop successfully sent frames if possible [much like:
"no news is good news!"].

But, TX_CTL_REQ_TX_STATUS was invented for a reason and
no tx status report should ever be dropped if it is set.

Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: Fix regression of register offset of AR9330/AR9340

The commit ce407afc10 introduced regression for AR9330/AR9340
register offsets. Some of the register offsets are common
for AR9330/AR9340/AR9485 except AR9380. Fix that.

Cc: stable@kernel.org [3.1.0+]
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: config hw when going back on-channel

When going back on-channel, we should reconfigure
the hw iff the hardware is not already configured
to the operational channel.

Signed-off-by: Eliad Peller <eliad@wizery.com>
Cc: stable@kernel.org # 2.6.39+
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: fix remain_off_channel regression

The offchannel code is currently broken - we should
remain_off_channel if the work was started, and
the work's channel and channel_type are the same
as local->tmp_channel and local->tmp_channel_type.

However, if wk->chan_type and local->tmp_channel_type
coexist (e.g. have the same channel type), we won't
remain_off_channel.

This behavior was introduced by commit da2fd1f
("mac80211: Allow work items to use existing
channel type.")

Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Eliad Peller <eliad@wizery.com>
Cc: stable@kernel.org # 2.6.39+
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: Fix radio retention for AR9462

IQ calibration during fast channel change sometimes failed
with RTT. And also restoring invalid radio retention readings
during init cal could cause failure to set the channel properly.
This patch counts the valid rtt history readings and clears
rtt mask.

Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: Fix regression of register offset for AR9003 chips

My recent commits (3782c69d, 324c74a) introduced regression
for register offset selection that based on the macversion.
Not using parentheses in proper manner for ternary operator
leads to select wrong offset for the registers.

This issue was observed with AR9462 chip that immediate disconnect
after the association with the following message

ieee80211 phy3: wlan0: Failed to send nullfunc to AP 00:23:69:12:ea:47
after 500ms, disconnecting.

Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

iwlagn: fix the race in the unmapping of the HCMD

As Stanislaw pointed out, my patch

iwlagn: fix a race in the unmapping of the TFDs

solved only part of the problem. The race still exists for TFDs of
the host commands. Fix that too.

Reported-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Merge branch 'master' of git://git./linux/kernel/git/padovan/bluetooth

Bluetooth: bfusb: Fix error path on firmware load

When loading the usb-configuration we do not signal the end of configuration on
memory allocation error. This patch moves the memory allocation to the top so
every error path uses "goto error" now to correctly send the usb-ctrl message
when detecting some error.

This also replaces GFP_ATOMIC with GFP_KERNEL as we are allowed to sleep here.

Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: bcm203x: Use GFP_KERNEL in workqueue

A workqueue is allowed to sleep so we can safely use GFP_KERNEL instead of
GFP_ATOMIC. This is still legacy code when the driver used timer BHs and not a
worqueue.

Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: bcm203x: Fix race condition on disconnect

When disconnecting a bcm203x device we kill and destroy the usb-urb, however,
there might still be a pending work-structure which resubmits the now invalid
urb. To avoid this race condition, we simply set a shutdown-flag and
synchronously kill the worker first.

This also adds a comment to all schedule_work()s, as it is really not clear
that they are used as replacement for short timers (which can be seen in the git
history).

Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: ath3k: Use GFP_KERNEL instead of GFP_ATOMIC

We are allowed to sleep here so no need to use GFP_ATOMIC. The caller
(ath3k_probe) calls request_firmware() which definitely sleeps. Hence, we should
avoid using GFP_ATOMIC.

Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: Set HCI_MGMT flag only in read_controller_info

The HCI_MGMT flag should only be set when user space requests the full
controller information. This way we avoid potential issues with setting
change events ariving before the actual read_controller_info command
finishes.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

Bluetooth: Increase HCI reset timeout in hci_dev_do_close

I've noticed that my CSR usb dongle was not working if it was plugged in when
PC was booting. It looks like I get two HCI reset command complete events (see
hcidump logs below).
The root cause is reset called from off_timer. Timeout for this reset to
complete is set to 250ms and my bt dongle requires more time for replying with
command complete event. After that, chip seems to reply with reset command
complete event for next non-reset command.

Attached patch increase mentioned timeout to HCI_INIT_TIMEOUT, this value is
already used for timeouting hci_reset_req in hci_dev_reset().

This might also be related to BT not working after suspend that was reported
here some time ago.

Hcidump log:

2011-09-12 23:13:27.379465 < HCI Command: Reset (0x03|0x0003) plen 0
2011-09-12 23:13:27.380797 > HCI Event: Command Complete (0x0e) plen 4
    Reset (0x03|0x0003) ncmd 1
    status 0x00
2011-09-12 23:13:27.380859 < HCI Command: Read Local Supported Features (0x04|0x000
3) plen 0
2011-09-12 23:13:27.760789 > HCI Event: Command Complete (0x0e) plen 4
    Reset (0x03|0x0003) ncmd 1
    status 0x00
2011-09-12 23:13:27.760831 < HCI Command: Read Local Version Information (0x04|0x00
01) plen 0
2011-09-12 23:13:27.764780 > HCI Event: Command Complete (0x0e) plen 12
    Read Local Version Information (0x04|0x0001) ncmd 1
    status 0x00
    HCI Version: 1.1 (0x1) HCI Revision: 0x36f
    LMP Version: 1.1 (0x1) LMP Subversion: 0x36f
    Manufacturer: Cambridge Silicon Radio (10)

Signed-off-by: Szymon Janc <szymon@janc.net.pl>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>

vlan: allow nested vlan_do_receive()

commit 2425717b27eb (net: allow vlan traffic to be received under bond)
broke ARP processing on vlan on top of bonding.

       +-------+
eth0 --| bond0 |---bond0.103
eth1 --|       |
       +-------+

52870.115435: skb_gro_reset_offset <-napi_gro_receive
52870.115435: dev_gro_receive <-napi_gro_receive
52870.115435: napi_skb_finish <-napi_gro_receive
52870.115435: netif_receive_skb <-napi_skb_finish
52870.115435: get_rps_cpu <-netif_receive_skb
52870.115435: __netif_receive_skb <-netif_receive_skb
52870.115436: vlan_do_receive <-__netif_receive_skb
52870.115436: bond_handle_frame <-__netif_receive_skb
52870.115436: vlan_do_receive <-__netif_receive_skb
52870.115436: arp_rcv <-__netif_receive_skb
52870.115436: kfree_skb <-arp_rcv

Packet is dropped in arp_rcv() because its pkt_type was set to
PACKET_OTHERHOST in the first vlan_do_receive() call, since no eth0.103
exists.

We really need to change pkt_type only if no more rx_handler is about to
be called for the packet.

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Reviewed-by: Jiri Pirko <jpirko@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ipv6: fix route lookup in addrconf_prefix_rcv()

The route lookup to find a previously auto-configured route for a prefixes used
to use rt6_lookup(), with the prefix from the RA used as an address. However,
that kind of lookup ignores routing tables, the prefix length and route flags,
so when there were other matching routes, even in different tables and/or with
a different prefix length, the wrong route would be manipulated.

Now, a new function "addrconf_get_prefix_route()" is used for the route lookup,
which searches in RT6_TABLE_PREFIX and takes the prefix-length and route flags
into account.

Signed-off-by: Andreas Hofmeister <andi@collax.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

bonding: eliminate bond_close race conditions

This patch resolves two sets of race conditions.

Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com> reported the
first, as follows:

The bond_close() calls cancel_delayed_work() to cancel delayed works.
It, however, cannot cancel works that were already queued in workqueue.
The bond_open() initializes work->data, and proccess_one_work() refers
get_work_cwq(work)->wq->flags. The get_work_cwq() returns NULL when
work->data has been initialized. Thus, a panic occurs.

He included a patch that converted the cancel_delayed_work calls
in bond_close to flush_delayed_work_sync, which eliminated the above
problem.

His patch is incorporated, at least in principle, into this
patch.  In this patch, we use cancel_delayed_work_sync in place of
flush_delayed_work_sync, and also convert bond_uninit in addition to
bond_close.

This conversion to _sync, however, opens new races between
bond_close and three periodically executing workqueue functions:
bond_mii_monitor, bond_alb_monitor and bond_activebackup_arp_mon.

The race occurs because bond_close and bond_uninit are always
called with RTNL held, and these workqueue functions may acquire RTNL to
perform failover-related activities.  If bond_close or bond_uninit is
waiting in cancel_delayed_work_sync, deadlock occurs.

These deadlocks are resolved by having the workqueue functions
acquire RTNL conditionally.  If the rtnl_trylock() fails, the functions
reschedule and return immediately.  For the cases that are attempting to
perform link failover, a delay of 1 is used; for the other cases, the
normal interval is used (as those activities are not as time critical).

Additionally, the bond_mii_monitor function now stores the delay
in a variable (mimicing the structure of activebackup_arp_mon).

Lastly, all of the above renders the kill_timers sentinel moot,
and therefore it has been removed.

Tested-by: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>