Conflicts:
	net/mac80211/mlme.c

When we remove a key, we put a key index which was supposed
to tell the fw that we are actually removing the key. But
instead the fw took that index as a valid index and messed
up the SRAM of the device.

This memory corruption on the device mangled the data of
the SCD. The impact on the user is that SCD queue 2 got
stuck after having removed keys.
Reported-by: NPaul Bolle <pebolle@tiscali.nl>
Cc: stable@vger.kernel.org
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is iwlegacy version of:

commit 342bbf3f
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Sun Mar 4 08:50:46 2012 -0800

    iwlwifi: always monitor for stuck queues

    If we only monitor while associated, the following
    can happen:
     - we're associated, and the queue stuck check
       runs, setting the queue "touch" time to X
     - we disassociate, stopping the monitoring,
       which leaves the time set to X
     - almost 2s later, we associate, and enqueue
       a frame
     - before the frame is transmitted, we monitor
       for stuck queues, and find the time set to
       X, although it is now later than X + 2000ms,
       so we decide that the queue is stuck and
       erroneously restart the device

Cc: stable@vger.kernel.org
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On rt2x00_dmastart() we increase index specified by Q_INDEX and on
rt2x00_dmadone() we increase index specified by Q_INDEX_DONE. So entries
between Q_INDEX_DONE and Q_INDEX are those we currently process in the
hardware. Entries between Q_INDEX and Q_INDEX_DONE are those we can
submit to the hardware.

According to that fix rt2x00usb_kick_queue(), as we need to submit RX
entries that are not processed by the hardware. It worked before only
for empty queue, otherwise was broken.

Note that for TX queues indexes ordering are ok. We need to kick entries
that have filled skb, but was not submitted to the hardware, i.e.
started from Q_INDEX_DONE and have ENTRY_DATA_PENDING bit set.

From practical standpoint this fixes RX queue stall, usually reproducible
in AP mode, like for example reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=828824Reported-and-tested-by: NFranco Miceli <fmiceli@plan.ceibal.edu.uy>
Reported-and-tested-by: NTom Horsley <horsley1953@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

> *. CID 709078: Resource leak (RESOURCE_LEAK)
> 	- drivers/net/wireless/mwifiex/cfg80211.c, line: 935
> Assigning: "bss_cfg" = storage returned from "kzalloc(132UL, 208U)"
> 	- but was not free
> drivers/net/wireless/mwifiex/cfg80211.c:935
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If association failed due to internal error (e.g. no
supported rates IE), we call ieee80211_destroy_assoc_data()
with assoc=true, while we actually reject the association.

This results in the BSSID not being zeroed out.

After passing assoc=false, we no longer have to call
sta_info_destroy_addr() explicitly. While on it, move
the "associated" message after the assoc_success check.

Cc: stable@vger.kernel.org [3.4+]
Signed-off-by: NEliad Peller <eliad@wizery.com>
Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

llcp_sock_getname can be called without a device attached to the nfc_llcp_sock.

This would lead to the following BUG:

[  362.341807] BUG: unable to handle kernel NULL pointer dereference at           (null)
[  362.341815] IP: [<ffffffff836258e5>] llcp_sock_getname+0x75/0xc0
[  362.341818] PGD 31b35067 PUD 30631067 PMD 0
[  362.341821] Oops: 0000 [#627] PREEMPT SMP DEBUG_PAGEALLOC
[  362.341826] CPU 3
[  362.341827] Pid: 7816, comm: trinity-child55 Tainted: G      D W    3.5.0-rc4-next-20120628-sasha-00005-g9f23eb7 #479
[  362.341831] RIP: 0010:[<ffffffff836258e5>]  [<ffffffff836258e5>] llcp_sock_getname+0x75/0xc0
[  362.341832] RSP: 0018:ffff8800304fde88  EFLAGS: 00010286
[  362.341834] RAX: 0000000000000000 RBX: ffff880033cb8000 RCX: 0000000000000001
[  362.341835] RDX: ffff8800304fdec4 RSI: ffff8800304fdec8 RDI: ffff8800304fdeda
[  362.341836] RBP: ffff8800304fdea8 R08: 7ebcebcb772b7ffb R09: 5fbfcb9c35bdfd53
[  362.341838] R10: 4220020c54326244 R11: 0000000000000246 R12: ffff8800304fdec8
[  362.341839] R13: ffff8800304fdec4 R14: ffff8800304fdec8 R15: 0000000000000044
[  362.341841] FS:  00007effa376e700(0000) GS:ffff880035a00000(0000) knlGS:0000000000000000
[  362.341843] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  362.341844] CR2: 0000000000000000 CR3: 0000000030438000 CR4: 00000000000406e0
[  362.341851] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  362.341856] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  362.341858] Process trinity-child55 (pid: 7816, threadinfo ffff8800304fc000, task ffff880031270000)
[  362.341858] Stack:
[  362.341862]  ffff8800304fdea8 ffff880035156780 0000000000000000 0000000000001000
[  362.341865]  ffff8800304fdf78 ffffffff83183b40 00000000304fdec8 0000006000000000
[  362.341868]  ffff8800304f0027 ffffffff83729649 ffff8800304fdee8 ffff8800304fdf48
[  362.341869] Call Trace:
[  362.341874]  [<ffffffff83183b40>] sys_getpeername+0xa0/0x110
[  362.341877]  [<ffffffff83729649>] ? _raw_spin_unlock_irq+0x59/0x80
[  362.341882]  [<ffffffff810f342b>] ? do_setitimer+0x23b/0x290
[  362.341886]  [<ffffffff81985ede>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[  362.341889]  [<ffffffff8372a539>] system_call_fastpath+0x16/0x1b
[  362.341921] Code: 84 00 00 00 00 00 b8 b3 ff ff ff 48 85 db 74 54 66 41 c7 04 24 27 00 49 8d 7c 24 12 41 c7 45 00 60 00 00 00 48 8b 83 28 05 00 00 <8b> 00 41 89 44 24 04 0f b6 83 41 05 00 00 41 88 44 24 10 0f b6
[  362.341924] RIP  [<ffffffff836258e5>] llcp_sock_getname+0x75/0xc0
[  362.341925]  RSP <ffff8800304fde88>
[  362.341926] CR2: 0000000000000000
[  362.341928] ---[ end trace 6d450e935ee18bf3 ]---
Signed-off-by: NSasha Levin <levinsasha928@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

msp has type struct minstrel_ht_sta_priv not struct minstrel_ht_sta.

(This incorporates the fixup originally posted as "mac80211: fix kzalloc
memory corruption introduced in minstrel_ht". -- JWL)
Reported-by: NFengguang Wu <wfg@linux.intel.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NThomas Huehn <thomas@net.t-labs.tu-berlin.de>
Acked-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

As we don't provide custom regulatory rules to cfg80211,
"chan->max_power" remains uninitialized (0dbm) and
"chan->max_reg_power" will contain maximum power for a channel
extracted from regulatory rules provided by CRDA; hence use
"chan->max_reg_power" in reg_notifier handler instead of
"chan->max_power" to set max_power in firmware.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since we don't support custom regulatory domains,
WIPHY_FLAG_CUSTOM_REGULATORY should not be enabled during wiphy
registration.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

"priv->max_tx_power_level" and "priv->min_tx_power_level" variables
are initialized to maximum and minimum power levels supported by
hardware by sending correct firmware command.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We miss to wakeup main thread after adding command to cmd pending
queue at follwing places. These commands are handled later when
main thread is woken up for handling an interrupt for sleep event
from firmware. This adds worst case delay of 50msec.

1) We don't wakeup main thread when asynchronous command is added
to cmd pending queue. Move queue_work() call from
mwifiex_wait_queue_complete() to mwifiex_send_cmd_async() to wakeup
main thread for sync as well as async commands.

2) Scan operation is triggered due to following reasons
   a) request from user (ex. "iw scan" command)
   b) Scan performed by driver internally.
   In first case main thread is woken up when first scan command is
queued in cmd pending queue (we don't need to wakeup main thread for
subsequent scan commands, because they are queued in scan command
response handler), but it is not done for second case. queue_work()
is moved inside mwifiex_scan_networks() to handle both the cases.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NAvinash Patil <patila@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The initvals tool from https://github.com/mcgrof/qca-swiss-army-knife has
been modified to detect identical initval tables and replace them with
macros. This patch contains the generated changes.

On MIPS this reduces the binary size by 24 KB with no runtime changes.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Generated using the initvals tool from the qca-swiss-army-knife repository
from https://github.com/mcgrof/qca-swiss-army-knifeSigned-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

seems i got a message like this
ath: phy0: BT_Status_Update: is_link=0, linkId=2,
state=1, SEQ=-2085766476 initially.
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ath9k_hw_mci_is_enabled wrapper also takes care of
ATH9K_HW_CAP_MCI being set for the AR9462 under test.
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ath9k_ani_reset (which is called at reset time) uses a state variable
ani->update_ani to prevent the ANI noise immunity state on the operating
channel from being overwritten by background scans. Unfortunately this
is also being set for AP mode, since it's mixed with code that is only
supposed to change the default settings after a reset.

In AP mode this has the side effect of having ANI run, but being unable to
change its runtime noise immunity level, making it effectively useless.

Fix this by getting rid of ani->update_ani and passing a parameter to
ath9k_hw_set_ofdm_nil and ath9k_hw_set_cck_nil instead.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Every now and then, after resuming from suspend, the iwlegacy driver
prints
    iwl4965 0000:03:00.0: Queue 2 stuck for 2000 ms.
    iwl4965 0000:03:00.0: On demand firmware reload

I have no idea what causes these errors. But the code currently uses
wd_timeout in the first error. wd_timeout will generally be set at
IL_DEF_WD_TIMEOUT (ie, 2000). Perhaps printing for how long the queue
was actually stuck can clarify the cause of these errors.
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Free ap_custom_ie before return from function.
Signed-off-by: NAvinash Patil <patila@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Wrap the MCI-work canceling with CONFIG_ATH9K_BTCOEX_SUPPORT.
Reported-by: NEmmanuel Benisty <benisty.e@gmail.com>
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The commit "brcmfmac: introduce checkdied debugfs functionality"
also introduced a sparse warning:

..../brcmfmac/dhd_sdio.c:3147:45: sparse: cast to restricted __le32

This patch fixes this sparse warning.
Reported-by: NFengguang Wu <wfg@linux.intel.com>
Reviewed-by: NFranky (Zhenhui) Lin <frankyl@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

BCM4334 is a dualband a/b/g/n WiFi chip support 20MHz/40MHz
channels. This patch adds support for its SDIO interface.
Reviewed-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The nvram data is preprocessed before being sent to the device
and just before sending an additional allocation was done that
assured word alignment of the data. This has moved to the
preprocessing step to reduce allocations and subsequent copying
of the nvram data.
Reviewed-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The nvram file could be parsed directly in the data buffer in the
firmware structure passed by request_firmware function. This patch
gets rid of the redundant memcpy.
Reviewed-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

txglomming alignment is a SDIO bus specific feature. It is more
appropriate to place it in SDIO bus layer instead of common layer.
Reviewed-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

txglomming is a firmware feature for sdio bus interface. For SDIO
device cores newer than revision 11, the default setting of
firmware should be used instead of disabling it from the host side.
Reviewed-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

brcmfmac need to support data command setting for dongle's bus
core. A list must be placed at brcmf_bus structure before calling
brcmf_bus_start in order to be sent by brcmf_c_preinit_dcmds.
Reviewed-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some of them are BCM4706 specific AFAWK. Most of them was confirmed on
Netgear WNDR450.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Commit 3a2923e8 introduced a bug when a corrupt descriptor
is encountered - although the following descriptor is discarded
and returned to the queue for reuse the associated frame is
also returned for processing. This leads to a panic:

BUG: unable to handle kernel NULL pointer dereference at 000000000000003a
IP: [<ffffffffa02599a5>] ath_rx_tasklet+0x165/0x1b00 [ath9k]
Call Trace:
<IRQ>
[<ffffffff812d7fa0>] ? map_single+0x60/0x60
[<ffffffffa028f044>] ? ath9k_ioread32+0x34/0x90 [ath9k]
[<ffffffffa0292eec>] athk9k_tasklet+0xdc/0x160 [ath9k]
[<ffffffff8105e133>] tasklet_action+0x63/0xd0
[<ffffffff8105dbc0>] __do_softirq+0xc0/0x1e0
[<ffffffff8101a873>] ? native_sched_clock+0x13/0x80
[<ffffffff815f9d5c>] call_softirq+0x1c/0x30
[<ffffffff810151f5>] do_softirq+0x75/0xb0
[<ffffffff8105df95>] irq_exit+0xb5/0xc0
[<ffffffff815fa5b3>] do_IRQ+0x63/0xe0
[<ffffffff815f0cea>] common_interrupt+0x6a/0x6a
<EOI>
[<ffffffff8131840a>] ? intel_idle+0xea/0x150
[<ffffffff813183eb>] ? intel_idle+0xcb/0x150
[<ffffffff814a1db9>] cpuidle_enter+0x19/0x20
[<ffffffff814a23d9>] cpuidle_idle_call+0xa9/0x240
[<ffffffff8101c4bf>] cpu_idle+0xaf/0x120
[<ffffffff815cda8e>] rest_init+0x72/0x74
[<ffffffff81cf4c1a>] start_kernel+0x3b7/0x3c4
[<ffffffff81cf4662>] ? repair_env_string+0x5e/0x5e
[<ffffffff81cf4346>] x86_64_start_reservations+0x131/0x135
[<ffffffff81cf444a>] x86_64_start_kernel+0x100/0x10f

Making sure bf is cleared to NULL in this case restores the
old behaviour.
Signed-off-by: NTom Hughes <tom@compton.nu>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When receiving an "individually addressed" action frame, the
receiver is required to return it to the sender. mac80211
gets this wrong as it also returns group addressed (mcast)
frames to the sender. Fix this and update the reference to
the new 802.11 standards version since things were shuffled
around significantly.

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

https://bugzilla.kernel.org/show_bug.cgi?id=42903

Based on the work of <fynivx@gmail.com>
Signed-off-by: NPanayiotis Karabassis <panayk@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The latest Realtek driver for the RTL8188CU and RTL8192CU chips adds three
new USB IDs.
Reported-by: NXose Vazquez Perez <xose.vazquez@gmail.com>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Remove the radio enable/disable stuff and fix the
transition to FULL_SLEEP mode when the device is idle.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Cancel the MCI work only when MCI is actually enabled.
Fixes this:

[96833.124051] Call Trace:
[96833.124060]  [<ffffffff810afaf8>] __lock_acquire+0x1518/0x1e40
[96833.124065]  [<ffffffff810ad126>] ? mark_held_locks+0x86/0x110
[96833.124069]  [<ffffffff810ad3ad>] ? trace_hardirqs_on+0xd/0x10
[96833.124073]  [<ffffffff814464f0>] ? _raw_spin_unlock_irq+0x30/0x70
[96833.124078]  [<ffffffff81072968>] ? wait_on_cpu_work+0x98/0xc0
[96833.124082]  [<ffffffff810b0a11>] lock_acquire+0xa1/0x150
[96833.124085]  [<ffffffff81072990>] ? wait_on_cpu_work+0xc0/0xc0
[96833.124088]  [<ffffffff81072990>] ? wait_on_cpu_work+0xc0/0xc0
[96833.124092]  [<ffffffff810729e2>] wait_on_work+0x52/0x120
[96833.124095]  [<ffffffff81072990>] ? wait_on_cpu_work+0xc0/0xc0
[96833.124099]  [<ffffffff81063b3f>] ? del_timer+0x7f/0x110
[96833.124102]  [<ffffffff81072c13>] __cancel_work_timer+0x83/0x130
[96833.124106]  [<ffffffff81072cf0>] cancel_work_sync+0x10/0x20
[96833.124113]  [<ffffffffa065b5cd>] __ath_cancel_work+0x4d/0x60 [ath9k]
[96833.124119]  [<ffffffffa065cf28>] ath9k_config+0x458/0x680 [ath9k]
[96833.124125]  [<ffffffffa065dd1e>] ? ath9k_flush+0x6e/0x1d0 [ath9k]
[96833.124129]  [<ffffffff8144394d>] ? __mutex_unlock_slowpath+0x10d/0x190
[96833.124146]  [<ffffffffa056c7b5>] ieee80211_hw_config+0x135/0x2a0 [mac80211]
[96833.124163]  [<ffffffffa057ebbb>] ieee80211_do_open+0x67b/0xc50 [mac80211]
[96833.124178]  [<ffffffffa057f1fd>] ieee80211_open+0x6d/0x80 [mac80211]
[96833.124183]  [<ffffffff8137a44f>] __dev_open+0x9f/0xf0
[96833.124187]  [<ffffffff8137a701>] __dev_change_flags+0xa1/0x180
[96833.124190]  [<ffffffff8137a898>] dev_change_flags+0x28/0x70
[96833.124195]  [<ffffffff813e1179>] devinet_ioctl+0x659/0x780
[96833.124199]  [<ffffffff8137aea0>] ? dev_ioctl+0x210/0x6d0
[96833.124203]  [<ffffffff813e1db5>] inet_ioctl+0x75/0x90
[96833.124208]  [<ffffffff8135e0e0>] sock_do_ioctl+0x30/0x70
[96833.124211]  [<ffffffff8135e3dd>] sock_ioctl+0x7d/0x2c0
[96833.124218]  [<ffffffff81193c39>] do_vfs_ioctl+0x99/0x580
[96833.124222]  [<ffffffff81447415>] ? sysret_check+0x22/0x5d
[96833.124226]  [<ffffffff811941b9>] sys_ioctl+0x99/0xa0
[96833.124230]  [<ffffffff814473e9>] system_call_fastpath+0x16/0x1b
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

mac80211 adds stations in HT IBSS as soon as a frame comes by,
even if the HT capabilities are not known yet (they are often
received later, e.g. in beacons). So far, ampdu factor/density
are only calculated when the station is initially added.

This patch changes this to update ampdu factor/density settings
when starting a blockack session.

Using this patch, we had performance boosts from 60 to 150 MBit/s
between two 2x2 Atheros devices in 5 GHz HT IBSS mode.
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The command "make includecheck" yields the following for the rtlwifi tree:

/home/finger/linux-2.6/drivers/net/wireless/rtlwifi/rtl8192se/sw.c: ../pci.h is included more than once.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The PCI-based drivers can generate the following warning:

[ 9497.776350] ------------[ cut here ]------------
[ 9497.776366] WARNING: at kernel/softirq.c:159 local_bh_enable_ip+0x7a/0xa0()
[ 9497.776370] Hardware name: 05794NC
[ 9497.776597] Pid: 6413, comm: hostapd Not tainted 3.3.0-4.fc16.x86_64 #1
[ 9497.776601] Call Trace:
[ 9497.776612]  [<ffffffff81057b1f>] warn_slowpath_common+0x7f/0xc0
[ 9497.776633]  [<ffffffffa034a099>] ? rtl_pci_reset_trx_ring+0x199/0x230
[rtlwifi]
[ 9497.776640]  [<ffffffff81057b7a>] warn_slowpath_null+0x1a/0x20
[ 9497.776646]  [<ffffffff8105f06a>] local_bh_enable_ip+0x7a/0xa0
[ 9497.776654]  [<ffffffff815f3ef6>] _raw_spin_unlock_bh+0x16/0x20
[ 9497.776671]  [<ffffffffa03e50de>] destroy_conntrack+0x9e/0x120
[nf_conntrack]
[ 9497.776681]  [<ffffffff81511847>] nf_conntrack_destroy+0x17/0x20
[ 9497.776689]  [<ffffffff814d9c85>] skb_release_head_state+0xe5/0x120
[ 9497.776695]  [<ffffffff814d98b6>] __kfree_skb+0x16/0xa0
[ 9497.776700]  [<ffffffff814d9a35>] kfree_skb+0x45/0xc0
[ 9497.776717]  [<ffffffffa034a099>] rtl_pci_reset_trx_ring+0x199/0x230
[rtlwifi]
[ 9497.776734]  [<ffffffffa034a155>] rtl_pci_start+0x25/0x1d0 [rtlwifi]
[ 9497.776750]  [<ffffffffa03440b5>] rtl_op_start+0x55/0x90 [rtlwifi]
[ 9497.776785]  [<ffffffffa02c4956>] ieee80211_do_open+0x296/0xa10 [mac80211]
[ 9497.776794]  [<ffffffff815f7ddd>] ? notifier_call_chain+0x4d/0x70
[ 9497.776828]  [<ffffffffa02c513d>] ieee80211_open+0x6d/0x80 [mac80211]
[ 9497.776836]  [<ffffffff814e8b3f>] __dev_open+0x8f/0xe0
[ 9497.776842]  [<ffffffff814e8de1>] __dev_change_flags+0xa1/0x180
[ 9497.776847]  [<ffffffff814e8f78>] dev_change_flags+0x28/0x70
[ 9497.776856]  [<ffffffff8154e99d>] devinet_ioctl+0x61d/0x7b0
[ 9497.776863]  [<ffffffff8154ef55>] inet_ioctl+0x75/0x90
[ 9497.776870]  [<ffffffff814cdd50>] sock_do_ioctl+0x30/0x70
[ 9497.776876]  [<ffffffff814cee09>] sock_ioctl+0x79/0x2f0
[ 9497.776885]  [<ffffffff81193498>] do_vfs_ioctl+0x98/0x550
[ 9497.776891]  [<ffffffff811939e1>] sys_ioctl+0x91/0xa0
[ 9497.776897]  [<ffffffff815fc029>] system_call_fastpath+0x16/0x1b
[ 9497.776902] ---[ end trace 22886c442489082d ]---

The cause is due to calling kfree_skb() with interrupts disabled.

This bug is discussed in https://bugzilla.redhat.com/show_bug.cgi?id=797709.

Reported-and-Tested by: Ivan Ivanovich <iivanich@gmail.com>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>