The regression was introduced in the following commit:

0967e01e
"ath5k: make use of the new rate control API"

ath5k_tx_frame_completed saves the intended per-rate retry counts before
they are cleared by ieee80211_tx_info_clear_status, however at this
point the information in info->status.rates is incomplete.

This causes significant throughput degradation and excessive packet loss
on links where high bit rates don't work properly.

Move the copy from bf->rates a few lines up to ensure that the saved
retry counts are updated, and that they are really cleared in
info->status.rates after the call to ieee80211_tx_info_clear_status.

Cc: stable@vger.kernel.org # 3.10+
Cc: Thomas Huehn <thomas@net.t-labs.tu-berlin.de>
Cc: Benjamin Vahl <bvahl@net.t-labs.tu-berlin.de>
Reported-by: NBen West <ben@gowasabi.net>
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Acked-by: NThomas Huehn <thomas@net.t-labs.tu-berlin.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since we set IEEE80211_HW_QUEUE_CONTROL, we can let
mac80211 do the queue assignement and don't need to
override its decisions.
While reassiging the same values is harmless of course,
it triggered  a WARNING when iwlwifi and mac80211 came
to different conclusions. This happened when mac80211 set
IEEE80211_TX_CTL_SEND_AFTER_DTIM, but didn't route the
packet to the cab_queue because no stations were asleep.

iwlwifi should not override mac80211's decicions for
offchannel packets and packets to  be sent after DTIM,
but it should override mac80211's decision for AMPDUs
since we have a special queue for them. So for AMPDU,
we still override info->hw_queue by the AMPDU queue.

This avoids:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 2531 at drivers/net/wireless/iwlwifi/dvm/tx.c:456 iwlagn_tx_skb+0x6c5/0x883()
Modules linked in:
CPU: 0 PID: 2531 Comm: hostapd Not tainted 3.12.0-rc5+ #1
Hardware name:                  /D53427RKE, BIOS RKPPT10H.86A.0017.2013.0425.1251 04/25/2013
 0000000000000000 0000000000000009 ffffffff8189aa62 0000000000000000
 ffffffff8105a4f2 ffff880058339a48 ffffffff815f8a04 0000000000000000
 ffff8800560097b0 0000000000000208 0000000000000000 ffff8800561a9e5e
Call Trace:
 [<ffffffff8189aa62>] ? dump_stack+0x41/0x51
 [<ffffffff8105a4f2>] ? warn_slowpath_common+0x78/0x90
 [<ffffffff815f8a04>] ? iwlagn_tx_skb+0x6c5/0x883
 [<ffffffff815f8a04>] ? iwlagn_tx_skb+0x6c5/0x883
 [<ffffffff818a0040>] ? put_cred+0x15/0x15
 [<ffffffff815f6db4>] ? iwlagn_mac_tx+0x19/0x2f
 [<ffffffff8186cc45>] ? __ieee80211_tx+0x226/0x29b
 [<ffffffff8186e6bd>] ? ieee80211_tx+0xa6/0xb5
 [<ffffffff8186e98b>] ? ieee80211_monitor_start_xmit+0x1e9/0x204
 [<ffffffff8171ce5f>] ? dev_hard_start_xmit+0x271/0x3ec
 [<ffffffff817351ac>] ? sch_direct_xmit+0x66/0x164
 [<ffffffff8171d1bf>] ? dev_queue_xmit+0x1e5/0x3c8
 [<ffffffff817fac5a>] ? packet_sendmsg+0xac5/0xb3d
 [<ffffffff81709a09>] ? sock_sendmsg+0x37/0x52
 [<ffffffff810f9e0c>] ? __do_fault+0x338/0x36b
 [<ffffffff81713820>] ? verify_iovec+0x44/0x94
 [<ffffffff81709e63>] ? ___sys_sendmsg+0x1f1/0x283
 [<ffffffff81140a73>] ? __inode_wait_for_writeback+0x67/0xae
 [<ffffffff8111735e>] ? __cache_free.isra.46+0x178/0x187
 [<ffffffff811173b1>] ? kmem_cache_free+0x44/0x84
 [<ffffffff81132c22>] ? dentry_kill+0x13d/0x149
 [<ffffffff81132f6f>] ? dput+0xe5/0xef
 [<ffffffff81136e04>] ? fget_light+0x2e/0x7c
 [<ffffffff8170ae62>] ? __sys_sendmsg+0x39/0x57
 [<ffffffff818a7e39>] ? system_call_fastpath+0x16/0x1b
---[ end trace 1b3eb79359c1d1e6 ]---
Reported-by: NSander Eikelenboom <linux@eikelenboom.it>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Some APs (notably a Sitecom WL-153 v1 with firmware 1.45) are sending
invalid WMM parameters setting AIFSN, ECWmin and ECWmax to zero. The
spec mandates that the value of AIFSN is at least 2, and some cards
(e.g. Intel with the iwldvm driver) can't transmit when the invalid
QoS parameters are actually uploaded to the firmware.

Since there's little chance of being able to guess the values that
the AP actually meant, disable WMM if such an invalid case is found.
Since ECWmin/ECWmax are allowed to be zero, only verify AIFSN >= 2
and ECWmin <= ECWmax.
Reviewed-by: NEliad Peller <eliad@wizery.com>
Reported-by: NAntonio Quartulli <antonio@meshcoding.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Bitrate mask were not respected in transmissions, causing (for
example) P2P GO/client to use CCK rates for auth and assoc frames.
Fix it by considering the rate mask in __rate_control_send_low().
Signed-off-by: NAndrei Otcheretianski <andrei.otcheretianski@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Transmissions with the IEEE80211_TX_CTL_NO_CCK_RATE flag set
(which can come from userspace) were no longer guaranteed to
be transmitted with allowed rates since commit 2103dec1
("mac80211: select and adjust bitrates according to channel
mode") due to a missing rate_flags check in that commit. The
commit also introduced the need to check the 5/10 MHz flags
but accidentally didn't. Fix it by adding the missing check.
Signed-off-by: NAndrei Otcheretianski <andrei.otcheretianski@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This patch adds missing cfg80211_disconnected event for P2P client
interface upon successful deauthenticate command, deauthenticate
event or disassociate event from FW.
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>

If device is surprise removed, commands sent to FW including
deauthenticate command fail as bus writes fail.
We update our media_connected status to false and inform cfg80211
about disconnection only when command is successful. Since cfg80211
assumes device is still connected, it results into following
WARN_ON during unload:

WARNING: CPU: 0 PID: 18245 at net/wireless/core.c:937
         cfg80211_netdev_notifier_call+0x175/0x4d0 [cfg80211]()

Avoid this by emitting cfg80211_disconnected event even if the
deauthenticate command fails.
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>

If a frame's timestamp is calculated, and the bitrate
calculation goes wrong and returns zero, the system
will attempt to divide by zero and crash. Catch this
case and print the rate information that the driver
reported when this happens.

Cc: stable@vger.kernel.org
Reported-by: NThomas Lindroth <thomas.lindroth@gmail.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When parsing an invalid radiotap header, the parser can overrun
the buffer that is passed in because it doesn't correctly check
 1) the minimum radiotap header size
 2) the space for extended bitmaps

The first issue doesn't affect any in-kernel user as they all
check the minimum size before calling the radiotap function.
The second issue could potentially affect the kernel if an skb
is passed in that consists only of the radiotap header with a
lot of extended bitmaps that extend past the SKB. In that case
a read-only buffer overrun by at most 4 bytes is possible.

Fix this by adding the appropriate checks to the parser.

Cc: stable@vger.kernel.org
Reported-by: NEvan Huus <eapache@gmail.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This fix is related to a scan request when associated (bgscan).
FW expects suspend time parameter in micro seconds while the driver
provides a value in time units. This bug leads to a high traffic
latency when scan is requested while traffic is in progress.
Signed-off-by: NAlexander Bondar <alexander.bondar@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When we restart firmware and it is marked as not alive, we can still get
calls from mac80211. Don't WARN on in this situation as this triggers
automatic bug reports with no valuable information.

This continuation of:

commit 8ca95995
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Sun Sep 15 11:37:17 2013 +0300

    iwlwifi: don't WARN on host commands sent when firmware is dead

which remove WARN_ONCE from one place, but those warnings are also
triggered from other functions.

Patch also adds unlikely() statement.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In certain corner cases in the firmware implementation, powersave
transitions can cause the firmware to miss the fact that commands
were added to the queue/FIFO and thus never processes them. Since
the commands really are in the queue, try to poke the firmware in
such cases (by grabbing NIC access, which wakes up the NIC) so it
notices the new command and processes it.
Reviewed-by: NAlexander Bondar <alexander.bondar@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This fixes "lost interrupt" problems that occurred on SPI-based systems.
cw1200_irq_handler() expects the hwbus to be locked, but on the
SPI-path, that lock wasn't taken (unlike in the SDIO-path, where the
generic SDIO-code takes care of acquiring the lock).

Cc: stable@vger.kernel.org
Signed-off-by: NDavid Mosberger <davidm@egauge.net>
Signed-off-by: NSolomon Peachy <pizza@shaftnet.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

An error in calculating the offset in an skb causes the driver to read
essential device info from the wrong locations. The main effect is that
automatic gain calculations are nonsense.
Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> [2.6.39+]
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since P2P device doesn't have a netdev associated to it,
we cannot prevent the user to start it when in RFKILL.
So refuse to even add it when in RFKILL.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

__ieee80211_scan_completed is called from a worker. This
means that the following flow is possible.

 * driver calls ieee80211_scan_completed
 * mac80211 cancels the scan (that is already complete)
 * __ieee80211_scan_completed runs

When scan_work will finally run, it will see that the scan
hasn't been aborted and might even trigger another scan on
another band. This leads to a situation where cfg80211's
scan is not done and no further scan can be issued.

Fix this by setting a new flag when a HW scan is being
cancelled so that no other scan will be triggered.

Cc: stable@vger.kernel.org
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The merge b35c8097 seems to have lost commit eabc4ac5,
put the code back.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Otherwise, if queues are full during a scan, tx scheduling does not
resume after switching back to the home channel.

Cc: stable@vger.kernel.org
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When RFKill cuts short a scan, mac80211 cancels the scan.
This is done by sending a host command to the firmware, but
this command was dropped because of RFKill. Flag this
command as "SEND_IN_RFKILL" to make sure it is sent to the
firmware. The firmware will send SCAN_COMPLETE_NOTIFICATION
which will trigger a call to ieee80211_scan_completed.

If the scan cannot be aborted, it is because the firmware
already finished the scan but we hadn't notified mac80211
at the time mac80211 decided to cancel the scan. By the time
we see the scan could not be aborted, mac80211 has been
notified already.

This patch fixes situations in which we didn't notify
mac80211 upon completion of the scan that was cut short
by RFkill.

Cc: stable@vger.kernel.org [3.10+]
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Add some new PCI IDs to the table for 6000, 6005 and 6235 series.

Cc: stable@vger.kernel.org
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This triggers automatic bug reports and add no valuable
information. Print a simple error instead and drop the
host command.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Add some new PCI IDs to the table for 7000 & 3160 series

Cc: stable@vger.kernel.org
Signed-off-by: NMatti Gottlieb <matti.gottlieb@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

A few NICs can get into trouble if we reset the TX queue
counters in certain very rare situation. To be on the safe
side, simply avoid to reset the TX queue counter.
This is relevant for non-AMPDU queues only since on AMPDU
we have no choice - we must start the TX queue at the right
index.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The D3 firmware image doesn't support uAPSD, so disable it.
Signed-off-by: NAlexander Bondar <alexander.bondar@intel.com>
Reviewed-by: NGuy Cohen <guy.cohen@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When a packet is passed from mac80211 to the driver with the
IEEE80211_TX_CTL_PS_RESPONSE flag set, it bypasses the normal driver
internal queueing and goes directly to the UAPSD queue.

When that happens, packets that are part of a BlockAck session still
need to be tracked as such inside the driver, otherwise it will create
discrepancies in the receiver BA reorder window, causing traffic stalls.
This only happens in AP mode with powersave-enabled clients.

This patch fixes the regression introduced in the commit
"ath9k: use software queues for un-aggregated data packets"
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

601216e1 "mwifiex: process RX packets in SDIO IRQ thread directly"
introduced a command timeout issue which can be reproduced easily on
an AM33xx platform using a test application written by Daniel Mack:

https://gist.github.com/zonque/6579314

mwifiex_main_process() is called from both the SDIO handler and
the workqueue. In case an interrupt occurs right after the
int_status check, but before updating the mwifiex_processing flag,
this interrupt gets lost, resulting in a command timeout and
consequently a card reset.

Let main_proc_lock protect both int_status and mwifiex_processing
flag. This fixes the interrupt lost issue.

Cc: <stable@vger.kernel.org> # 3.7+
Reported-by: NSven Neumann <s.neumann@raumfeld.com>
Reported-by: NAndreas Fenkart <andreas.fenkart@streamunlimited.com>
Tested-by: NDaniel Mack <zonque@gmail.com>
Reviewed-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NPaul Stewart <pstew@chromium.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This reverts commit 9483f40d.

Some devices stop to connect with above commit, see:
https://bugzilla.kernel.org/show_bug.cgi?id=61621

Since there is no clear benefit of having MSI enabled, just revert
change to fix the problem.

Cc: stable@vger.kernel.org # 3.11+
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NJakub Kicinski <kubakici@wp.pl>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

mac80211 scan processing could get stuck if roc work for pending, but
not started when a scan request was deferred due to such roc item.
Normally the deferred scan would be started from
ieee80211_start_next_roc(), but ieee80211_sw_roc_work() calls that only
if the finished ROC was started. Fix this by calling
ieee80211_run_deferred_scan() in the case the last ROC was not actually
started.

This issue was hit relatively easily in P2P find operations where Listen
state (remain-on-channel) and Search state (scan) are repeated in a
loop.
Signed-off-by: NJouni Malinen <j@w1.fi>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When clients are idle for too long, hostapd sends nullfunc frames for
probing. When those are acked by the client, the idle time needs to be
updated.

To make this work (and to avoid unnecessary probing), update sta->last_rx
whenever an ACK was received for a tx packet. Only do this if the flag
IEEE80211_HW_REPORTS_TX_ACK_STATUS is set.

Cc: stable@vger.kernel.org
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This allows calls for clients in AP_VLANs (e.g. for 4-addr) to succeed

Cc: stable@vger.kernel.org
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

My locking rework/race fixes caused a regression in the
registration, causing uevent notifications for wireless
devices before the device is really fully registered and
available in nl80211.

Fix this by moving the device_add() under rtnl and move
the rfkill to afterwards (it can't be under rtnl.)
Reported-and-tested-by: NMaxime Bizon <mbizon@freebox.fr>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This patch adds explicit call to bcma_core_pci_power_save() from
a non-atomic context resolving 'scheduling while atomic' issue.

[   13.224317] BUG: scheduling while atomic: dhcpcd/1800/0x00000202
[   13.224322] Modules linked in: brcmsmac nouveau coretemp kvm_intel kvm cordic brcmutil bcma dell_wmi atl1c ttm mxm_wmi wmi
[   13.224354] CPU: 0 PID: 1800 Comm: dhcpcd Tainted: G        W    3.11.0-wl #1
[   13.224359] Hardware name: Alienware M11x R2/M11x R2, BIOS A04 11/23/2010
[   13.224363]  ffff880177c12c40 ffff880170fd1968 ffffffff8169af5b 0000000000000007
[   13.224374]  ffff880170fd1ad0 ffff880170fd1978 ffffffff81697ee2 ffff880170fd19f8
[   13.224383]  ffffffff816a19f5 00000000000f4240 000000000000d080 ffff880170fd1fd8
[   13.224391] Call Trace:
[   13.224399]  [<ffffffff8169af5b>] dump_stack+0x4f/0x84
[   13.224403]  [<ffffffff81697ee2>] __schedule_bug+0x43/0x51
[   13.224409]  [<ffffffff816a19f5>] __schedule+0x6e5/0x810
[   13.224412]  [<ffffffff816a1c34>] schedule+0x24/0x70
[   13.224416]  [<ffffffff816a04fc>] schedule_hrtimeout_range_clock+0x10c/0x150
[   13.224420]  [<ffffffff810684e0>] ? update_rmtp+0x60/0x60
[   13.224424]  [<ffffffff8106915f>] ? hrtimer_start_range_ns+0xf/0x20
[   13.224429]  [<ffffffff816a054e>] schedule_hrtimeout_range+0xe/0x10
[   13.224432]  [<ffffffff8104f6fb>] usleep_range+0x3b/0x40
[   13.224437]  [<ffffffffa003733a>] bcma_pcie_mdio_read.isra.5+0x8a/0x100 [bcma]
[   13.224442]  [<ffffffffa00374a5>] bcma_pcie_mdio_writeread.isra.6.constprop.13+0x25/0x30 [bcma]
[   13.224448]  [<ffffffffa00374f9>] bcma_core_pci_power_save+0x49/0x80 [bcma]
[   13.224452]  [<ffffffffa003765d>] bcma_core_pci_up+0x2d/0x60 [bcma]
[   13.224460]  [<ffffffffa03dc17c>] brcms_c_up+0xfc/0x430 [brcmsmac]
[   13.224467]  [<ffffffffa03d1a7d>] brcms_up+0x1d/0x20 [brcmsmac]
[   13.224473]  [<ffffffffa03d2498>] brcms_ops_start+0x298/0x340 [brcmsmac]
[   13.224478]  [<ffffffff81600a12>] ? cfg80211_netdev_notifier_call+0xd2/0x5f0
[   13.224483]  [<ffffffff815fa53d>] ? packet_notifier+0xad/0x1d0
[   13.224487]  [<ffffffff81656e75>] ieee80211_do_open+0x325/0xf80
[   13.224491]  [<ffffffff8106ac09>] ? __raw_notifier_call_chain+0x9/0x10
[   13.224495]  [<ffffffff81657b41>] ieee80211_open+0x71/0x80
[   13.224498]  [<ffffffff81526267>] __dev_open+0x87/0xe0
[   13.224502]  [<ffffffff8152650c>] __dev_change_flags+0x9c/0x180
[   13.224505]  [<ffffffff815266a3>] dev_change_flags+0x23/0x70
[   13.224509]  [<ffffffff8158cd68>] devinet_ioctl+0x5b8/0x6a0
[   13.224512]  [<ffffffff8158d5c5>] inet_ioctl+0x75/0x90
[   13.224516]  [<ffffffff8150b38b>] sock_do_ioctl+0x2b/0x70
[   13.224519]  [<ffffffff8150b681>] sock_ioctl+0x71/0x2a0
[   13.224523]  [<ffffffff8114ed47>] do_vfs_ioctl+0x87/0x520
[   13.224528]  [<ffffffff8113f159>] ? ____fput+0x9/0x10
[   13.224533]  [<ffffffff8106228c>] ? task_work_run+0x9c/0xd0
[   13.224537]  [<ffffffff8114f271>] SyS_ioctl+0x91/0xb0
[   13.224541]  [<ffffffff816aa252>] system_call_fastpath+0x16/0x1b

Cc: <stable@vger.kernel.org> # 3.11.x
Cc: Tod Jackson <tod.jackson@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Rafal Milecki <zajec5@gmail.com>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch removes the bcma_core_pci_power_save() call from
the bcma_core_pci_{up,down}() functions as it tries to schedule
thus requiring to call them from non-atomic context. The function
bcma_core_pci_power_save() is now exported so the calling module
can explicitly use it in non-atomic context. This fixes the
'scheduling while atomic' issue reported by Tod Jackson and
Joe Perches.

[   13.210710] BUG: scheduling while atomic: dhcpcd/1800/0x00000202
[   13.210718] Modules linked in: brcmsmac nouveau coretemp kvm_intel kvm cordic brcmutil bcma dell_wmi atl1c ttm mxm_wmi wmi
[   13.210756] CPU: 2 PID: 1800 Comm: dhcpcd Not tainted 3.11.0-wl #1
[   13.210762] Hardware name: Alienware M11x R2/M11x R2, BIOS A04 11/23/2010
[   13.210767]  ffff880177c92c40 ffff880170fd1948 ffffffff8169af5b 0000000000000007
[   13.210777]  ffff880170fd1ab0 ffff880170fd1958 ffffffff81697ee2 ffff880170fd19d8
[   13.210785]  ffffffff816a19f5 00000000000f4240 000000000000d080 ffff880170fd1fd8
[   13.210794] Call Trace:
[   13.210813]  [<ffffffff8169af5b>] dump_stack+0x4f/0x84
[   13.210826]  [<ffffffff81697ee2>] __schedule_bug+0x43/0x51
[   13.210837]  [<ffffffff816a19f5>] __schedule+0x6e5/0x810
[   13.210845]  [<ffffffff816a1c34>] schedule+0x24/0x70
[   13.210855]  [<ffffffff816a04fc>] schedule_hrtimeout_range_clock+0x10c/0x150
[   13.210867]  [<ffffffff810684e0>] ? update_rmtp+0x60/0x60
[   13.210877]  [<ffffffff8106915f>] ? hrtimer_start_range_ns+0xf/0x20
[   13.210887]  [<ffffffff816a054e>] schedule_hrtimeout_range+0xe/0x10
[   13.210897]  [<ffffffff8104f6fb>] usleep_range+0x3b/0x40
[   13.210910]  [<ffffffffa00371af>] bcma_pcie_mdio_set_phy.isra.3+0x4f/0x80 [bcma]
[   13.210921]  [<ffffffffa003729f>] bcma_pcie_mdio_write.isra.4+0xbf/0xd0 [bcma]
[   13.210932]  [<ffffffffa0037498>] bcma_pcie_mdio_writeread.isra.6.constprop.13+0x18/0x30 [bcma]
[   13.210942]  [<ffffffffa00374ee>] bcma_core_pci_power_save+0x3e/0x80 [bcma]
[   13.210953]  [<ffffffffa003765d>] bcma_core_pci_up+0x2d/0x60 [bcma]
[   13.210975]  [<ffffffffa03dc17c>] brcms_c_up+0xfc/0x430 [brcmsmac]
[   13.210989]  [<ffffffffa03d1a7d>] brcms_up+0x1d/0x20 [brcmsmac]
[   13.211003]  [<ffffffffa03d2498>] brcms_ops_start+0x298/0x340 [brcmsmac]
[   13.211020]  [<ffffffff81600a12>] ? cfg80211_netdev_notifier_call+0xd2/0x5f0
[   13.211030]  [<ffffffff815fa53d>] ? packet_notifier+0xad/0x1d0
[   13.211064]  [<ffffffff81656e75>] ieee80211_do_open+0x325/0xf80
[   13.211076]  [<ffffffff8106ac09>] ? __raw_notifier_call_chain+0x9/0x10
[   13.211086]  [<ffffffff81657b41>] ieee80211_open+0x71/0x80
[   13.211101]  [<ffffffff81526267>] __dev_open+0x87/0xe0
[   13.211109]  [<ffffffff8152650c>] __dev_change_flags+0x9c/0x180
[   13.211117]  [<ffffffff815266a3>] dev_change_flags+0x23/0x70
[   13.211127]  [<ffffffff8158cd68>] devinet_ioctl+0x5b8/0x6a0
[   13.211136]  [<ffffffff8158d5c5>] inet_ioctl+0x75/0x90
[   13.211147]  [<ffffffff8150b38b>] sock_do_ioctl+0x2b/0x70
[   13.211155]  [<ffffffff8150b681>] sock_ioctl+0x71/0x2a0
[   13.211169]  [<ffffffff8114ed47>] do_vfs_ioctl+0x87/0x520
[   13.211180]  [<ffffffff8113f159>] ? ____fput+0x9/0x10
[   13.211198]  [<ffffffff8106228c>] ? task_work_run+0x9c/0xd0
[   13.211202]  [<ffffffff8114f271>] SyS_ioctl+0x91/0xb0
[   13.211208]  [<ffffffff816aa252>] system_call_fastpath+0x16/0x1b
[   13.211217] NOHZ: local_softirq_pending 202

The issue was introduced in v3.11 kernel by following commit:

commit aa51e598
Author: Hauke Mehrtens <hauke@hauke-m.de>
Date:   Sat Aug 24 00:32:31 2013 +0200

    brcmsmac: use bcma PCIe up and down functions

    replace the calls to bcma_core_pci_extend_L1timer() by calls to the
    newly introduced bcma_core_pci_ip() and bcma_core_pci_down()
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
    Cc: Arend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This fix has been discussed with Hauke Mehrtens [1] selection
option 3) and is intended for v3.12.

Ref:
[1] http://mid.gmane.org/5239B12D.3040206@hauke-m.de

Cc: <stable@vger.kernel.org> # 3.11.x
Cc: Tod Jackson <tod.jackson@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Rafal Milecki <zajec5@gmail.com>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The driver uses platform_driver_probe() to obtain platform data
if any. However, that function is placed in the .init section so
it must be called upon driver module initialization.

The problem was reported by Fenguang Wu resulting in a kernel
oops because the .init section was already freed.

[   48.966342] Switched to clocksource tsc
[   48.970002] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
[   48.970851] BUG: unable to handle kernel paging request at ffffffff82196446
[   48.970957] IP: [<ffffffff82196446>] classes_init+0x26/0x26
[   48.970957] PGD 1e76067 PUD 1e77063 PMD f388063 PTE 8000000002196163
[   48.970957] Oops: 0011 [#1]
[   48.970957] CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 3.11.0-rc7-00444-gc52dd7f #23
[   48.970957] Workqueue: events brcmf_driver_init
[   48.970957] task: ffff8800001d2000 ti: ffff8800001d4000 task.ti: ffff8800001d4000
[   48.970957] RIP: 0010:[<ffffffff82196446>]  [<ffffffff82196446>] classes_init+0x26/0x26
[   48.970957] RSP: 0000:ffff8800001d5d40  EFLAGS: 00000286
[   48.970957] RAX: 0000000000000001 RBX: ffffffff820c5620 RCX: 0000000000000000
[   48.970957] RDX: 0000000000000001 RSI: ffffffff816f7380 RDI: ffffffff820c56c0
[   48.970957] RBP: ffff8800001d5d50 R08: ffff8800001d2508 R09: 0000000000000002
[   48.970957] R10: 0000000000000000 R11: 0001f7ce298c5620 R12: ffff8800001c76b0
[   48.970957] R13: ffffffff81e91d40 R14: 0000000000000000 R15: ffff88000e0ce300
[   48.970957] FS:  0000000000000000(0000) GS:ffffffff81e84000(0000) knlGS:0000000000000000
[   48.970957] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[   48.970957] CR2: ffffffff82196446 CR3: 0000000001e75000 CR4: 00000000000006b0
[   48.970957] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   48.970957] DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000
[   48.970957] Stack:
[   48.970957]  ffffffff816f7df8 ffffffff820c5620 ffff8800001d5d60 ffffffff816eeec9
[   48.970957]  ffff8800001d5de0 ffffffff81073dc5 ffffffff81073d68 ffff8800001d5db8
[   48.970957]  0000000000000086 ffffffff820c5620 ffffffff824f7fd0 0000000000000000
[   48.970957] Call Trace:
[   48.970957]  [<ffffffff816f7df8>] ? brcmf_sdio_init+0x18/0x70
[   48.970957]  [<ffffffff816eeec9>] brcmf_driver_init+0x9/0x10
[   48.970957]  [<ffffffff81073dc5>] process_one_work+0x1d5/0x480
[   48.970957]  [<ffffffff81073d68>] ? process_one_work+0x178/0x480
[   48.970957]  [<ffffffff81074188>] worker_thread+0x118/0x3a0
[   48.970957]  [<ffffffff81074070>] ? process_one_work+0x480/0x480
[   48.970957]  [<ffffffff8107aa17>] kthread+0xe7/0xf0
[   48.970957]  [<ffffffff810829f7>] ? finish_task_switch.constprop.57+0x37/0xd0
[   48.970957]  [<ffffffff8107a930>] ? __kthread_parkme+0x80/0x80
[   48.970957]  [<ffffffff81a6923a>] ret_from_fork+0x7a/0xb0
[   48.970957]  [<ffffffff8107a930>] ? __kthread_parkme+0x80/0x80
[   48.970957] Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
cc cc cc cc cc cc <cc> cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
[   48.970957] RIP  [<ffffffff82196446>] classes_init+0x26/0x26
[   48.970957]  RSP <ffff8800001d5d40>
[   48.970957] CR2: ffffffff82196446
[   48.970957] ---[ end trace 62980817cd525f14 ]---

Cc: <stable@vger.kernel.org> # 3.10.x, 3.11.x
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Tested-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>