Need to use broadcast sta_id for management frames, otherwise we broke
BA session in the firmware and get messages like that:

"Received BA when not expected"

or (on older kernels):

"BA scd_flow 0 does not match txq_id 10"

This fix regression introduced in 2.6.35 during station management
code rewrite by:

commit 2a87c26b
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Apr 30 11:30:45 2010 -0700

    iwlwifi: use iwl_find_station less
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Need to use broadcast sta_id for management frames, otherwise we broke
BA session in the firmware and get messages like that:

"Received BA when not expected"

or (on older kernels):

"BA scd_flow 0 does not match txq_id 10"

This fix regression introduced in 2.6.35 during station management
code rewrite by:

commit 2a87c26b
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Apr 30 11:30:45 2010 -0700

    iwlwifi: use iwl_find_station less

Patch partially resolve:
https://bugzilla.kernel.org/show_bug.cgi?id=16691
However, there are still 11n performance problems on 4965 and 5xxx
devices that need to be investigated.

Cc: stable@kernel.org # 2.6.35+
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NJohannes Berg <johannes@sipsolutions.net>
Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix the following:

WARNING: at drivers/net/wireless/iwlegacy/iwl-4965.c:1128 \
iwl4965_send_tx_power+0x61/0x102 [iwl4965]() Hardware name: [...]
TX Power requested while scanning!

Pid: 5723, comm: kworker/u:28 Not tainted 2.6.39-0.rc4.4.fc14.x86_64 #1
Call Trace:
 [<ffffffff8104e27b>] warn_slowpath_common+0x85/0x9d
 [<ffffffffa02782e0>] ? iwl4965_show_temperature+0x49/0x49 [iwl4965]
 [<ffffffff8104e336>] warn_slowpath_fmt+0x46/0x48
 [<ffffffffa027712f>] iwl4965_send_tx_power+0x61/0x102 [iwl4965]
 [<ffffffff81477e05>] ? mutex_lock+0x36/0x50
 [<ffffffffa0278337>] iwl4965_bg_txpower_work+0x57/0x73 [iwl4965]
 [<ffffffff810647f3>] process_one_work+0x18d/0x286
 [<ffffffff81065a5e>] worker_thread+0xfd/0x181
 [<ffffffff81065961>] ? manage_workers.clone.16+0x172/0x172
 [<ffffffff81069036>] kthread+0x82/0x8a
 [<ffffffff81480524>] kernel_thread_helper+0x4/0x10
 [<ffffffff81068fb4>] ? kthread_worker_fn+0x14b/0x14b
 [<ffffffff81480520>] ? gs_change+0x13/0x13
Reported-and-tested-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

commit 5ed540ae change the led behavior
for iwlwifi driver; the side effect cause led blink all the time.

Modify the led blink table to fix this problem
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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

Since

commit a120e912
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Fri Feb 19 15:47:33 2010 -0800

    iwlwifi: sanity check before counting number of tfds can be free

we use skb->data after calling ieee80211_tx_status_irqsafe(), which
could free skb instantly.

On current kernels I do not observe practical problems related with
bug, but on 2.6.35.y it cause random system hangs when stressing
wireless link, making bisection of other problems impossible.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since

commit a120e912
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Fri Feb 19 15:47:33 2010 -0800

    iwlwifi: sanity check before counting number of tfds can be free

we use skb->data after calling ieee80211_tx_status_irqsafe(), which
could free skb instantly.

On current kernels I do not observe practical problems related with
bug, but on 2.6.35.y it cause random system hangs when stressing
wireless link.

Cc: stable@kernel.org # 2.6.32+
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The patch 'ath9k_hw: fix stopping rx DMA during resets' added code to detect
a condition where rx DMA was stopped, but the MAC failed to enter the idle
state. This condition requires a hardware reset, however the return value
of ath_stoprecv was 'true' in that case, which allowed it to skip the reset
when issuing a fast channel change.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Reported-by: NPaul Stewart <pstew@google.com>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

For some reason, sending QoS configuration causes transmission to stop
after a single frame on HT channels when not associated. Removing the
extra QoS configuration has no effect on station mode, and fixes
injection mode.
Signed-off-by: NDaniel Halperin <dhalperi@cs.washington.edu>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

priv->tx_power_next is not initialized to max supported power,
but instead default value is used, what cause errors like

[   58.597834] iwl3945 0000:03:00.0: Requested user TXPOWER 15 above upper limit 14.
[   58.597839] iwl3945 0000:03:00.0: Error setting Tx power (-22).

if maximum tx power read from the eeprom is smaller than default.
In consequence card is unable to initialize properly. Fix the problem
and cleanup tx power initialization.
Reported-and-tested-by: NRobin Dong <hao.bigrat@gmail.com>
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Pass the correct module name and device interface so that
ethtool can display the proper values.

The firmware version will be fixed later on when the FW
can actually report a version. :)
Reported-by: NRichard Farina <sidhayn@gmail.com>
Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com>
Tested-by: NRichard Farina <sidhayn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

During PHY errors, the MAC can sometimes fail to enter an idle state on older
hardware (before AR9380) after an rx stop has been requested.

This typically shows up in the kernel log with messages like these:

ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
------------[ cut here ]------------
WARNING: at drivers/net/wireless/ath/ath9k/recv.c:504 ath_stoprecv+0xcc/0xf0 [ath9k]()
Call Trace:
[<8023f0e8>] dump_stack+0x8/0x34
[<80075050>] warn_slowpath_common+0x78/0xa4
[<80075094>] warn_slowpath_null+0x18/0x24
[<80d66d60>] ath_stoprecv+0xcc/0xf0 [ath9k]
[<80d642cc>] ath_set_channel+0xbc/0x270 [ath9k]
[<80d65254>] ath_radio_disable+0x4a4/0x7fc [ath9k]

When this happens, the state that the MAC enters is easy to identify and
does not result in bogus DMA traffic, however to ensure a working state
after a channel change, the hardware should still be reset.

This patch adds detection for this specific MAC state, after which the above
warnings completely disappear in my tests.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Cc: Kyungwan Nam <Kyungwan.Nam@Atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Otherwise, IWLWIFI_LEGACY has to be selected independently before the
drivers are made available.
Reported-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Wey-Yi Guy <wey-yi.w.guy@intel.com>

This patch fixes a very serious off-by-one bug in
the driver, which could leave the device in an
unresponsive state.

The problem was that the extra_len variable [used to
reserve extra scratch buffer space for the firmware]
was left uninitialized. Because p54_assign_address
later needs the value to reserve additional space,
the resulting frame could be to big for the small
device's memory window and everything would
immediately come to a grinding halt.

Reference: https://bugs.launchpad.net/bugs/722185

Cc: <stable@kernel.org>
Acked-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJason Conti <jason.conti@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

These missing chip wakeups mainly cause crashes on AR5416 cards in MIPS
boards, but have also been reported to cause radio stability issues on
AR9285.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Joe Culler reported a problem with his AR9170 device:

> ath: EEPROM regdomain: 0x5c
> ath: EEPROM indicates we should expect a direct regpair map
> ath: invalid regulatory domain/country code 0x5c
> ath: Invalid EEPROM contents

It turned out that the regdomain 'APL7_FCCA' was not mapped yet.
According to Luis R. Rodriguez [Atheros' engineer] APL7 maps to
FCC_CTL and FCCA maps to FCC_CTL as well, so the attached patch
should be correct.

Cc: <stable@kernel.org>
Reported-by: NJoe Culler <joe.culler@gmail.com>
Acked-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When the mwl8k driver attempts and fails to switch from sta to ap
firmware (or vice-versa) in the mwl8k_add_interface routine, the
mwl8k_stop routine will be called. This routine must not attempt
to free the irq if it was not requested.
Signed-off-by: NBrian Cavagnolo <brian@cozybit.com>
Signed-off-by: NNishant Sarmukadam <nishants@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

At least EEPROM version 0x11A has the wrong
number of chains programmed into it for some
reason, so we need to override in the driver.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

A number of these devices have appeared "in the wild", and apparently
the Windows driver is perfectly happy to support this EEPROM version.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Cc: stable@kernel.org
Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

{rx,tx}done_work's are only initialized for usb devices.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Cc: stable@kernel.org
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some compiler/architecture combinations generate some warnings that are
not seen on my main system. Two of the "warnings" about unitialized variables
are really bugs.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Cc: <stable@kernel.org>
Reported-by: Mark Davis [via p54/devices wiki]
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We were allocating the size of the NVS file struct and not checking
whether the length of the buffer passed was correct before copying it
into the allocated memory.  This is a security hole because buffer
overflows can occur if the userspace passes a bigger file than what is
expected.

With this patch, we check if the size of the data passed from
userspace matches the size required.

This bug was introduced in 2.6.36.

Cc: stable@kernel.org
Reported-by: NIdo Yariv <ido@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

2.6.38 added WARN_ON(in_irq) in del_timer_sync that triggers on zd1211rw when
reseting rx idle timer in urb completion handler.

Move timer reseting to tasklet.
Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Patch removes the bogus flag introduced by upstream commit
eefdbec1. Old code had buffer length check
that new code tried to handle with URB_SHORT_NOT_OK flag. With USB debugging
enabled bogus flag caused usb_submit_urb fail.

Remove URB_SHORT_NOT_OK flag and add buffer length check to urb completion
handler.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=32092Reported-by: NJonathan Callen <abcd@gentoo.org>
Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The phy information print during driver init time doesn't show
the numeric part of the chip name properly for AR9485. This patch
addresses this issue by adding the string to the respective array.
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The MODULE_AUTHOR() macro in the main module (wl12xx) has been updated
to reflect one of the author's new email address, but the wl12xx_spi
and wl12xx_sdio modules haven't been updated.  This patches updates
them.
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Otherwise, skb_put inside of dma_rx can fail...

	https://bugzilla.kernel.org/show_bug.cgi?id=32042Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: stable@kernel.org

Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>

If change_interface gets invoked during a firmware
restart, it may crash; prevent that from happening
by checking if ctx->vif is assigned.

Additionally, in my initial commit I forgot to set
the vif->p2p variable correctly, so fix that too.

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

Some clients seem to rely upon the reception of BlockAckReqs to flush
their rx reorder buffer. In order to fix aggregation for these clients
carl9170 should set IEEE80211_TX_STAT_AMPDU_NO_BACK to generate a
BlockAckReq if the transmission of an AMPDU subframe fails.

This fixes aggregation problems with Intel 5100 Windows STAs (and maybe
others as well).
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

After new NetworkManager 0.8.996 changes, hardware scanning is causing
microcode errors as reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=683571
and sometimes kernel crashes:
https://bugzilla.redhat.com/show_bug.cgi?id=688252

Also with hw scan there are very bad performance on some systems
as reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=671366

Since Intel no longer supports 3945, there is no chance to get proper
firmware fixes, we need workaround problems by disable hardware scanning
by default.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

taken from staging/rt2860
0x0411,0x016f de37cd49 MelCo(Buffalo) WLI-UC-G301N
0x050d,0x825b 12840c63 Belkin F5D8055
0x050d,0x935a 705059a6 Belkin F6D4050 v1
0x050d,0x935b 5d92fe33 Belkin F6D4050 v2

identifed from ralink driverss
0x0930,0x0a07 RT35xx TOSHIBA 2010_1215_RT3572_Linux_STA_v2.5.0.0.DPO
0x1d4d,0x0011 3072 Pegatron 2011_0107_RT3070_RT3370_Linux_STA_v2.5.0.1_DPO
Signed-off-by: NXose Vazquez Perez <xose.vazquez@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Software scanning can be used for workaround some performance problems,
so do not deprecate it.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Scripted with coccinelle.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

When the chip is still asleep when ath9k_start is called,
ath9k_hw_configpcipowersave can trigger a data bus error.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

commit 86271e46 introduced a
regression that caused mac80211 queues in stopped state.

ath_drain_all_txq is called in driver flush which would reset
the stopped flag and the mac80211 queues were never started
after that. iperf traffic is completely stalled due to this issue.

Restart the mac80211 queues in driver flush only if the txqs were
drained.
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

With the recent tx status optimization in mac80211, we bail out as
and and when invalid rate index is found. So the behavior of resetting
rate idx to -1 and count to 0 has changed for the rate indexes that
were not part of the driver's retry series.

This has resulted in ath9k using incorrect rate table index which
caused the system to panic. Ideally ath9k need to loop only for the
indexes that were part of the retry series and so simply use hw->max_rates
as the loop counter.

Pasted the stack trace of the panic issue for reference.

[  754.093192] BUG: unable to handle kernel paging request at ffff88046a9025b0
[  754.093256] IP: [<ffffffffa02eac49>] ath_tx_status+0x209/0x2f0 [ath9k]
[  754.094888] Call Trace:
[  754.094903]  <IRQ>
[  754.094928]  [<ffffffffa051f883>] ieee80211_tx_status+0x203/0x9e0 [mac80211]
[  754.094975]  [<ffffffffa053e305>] ? __ieee80211_wake_queue+0x125/0x140 [mac80211]
[  754.095017]  [<ffffffffa02e66c9>] ath_tx_complete_buf+0x1b9/0x370 [ath9k]
[  754.095054]  [<ffffffffa02e6fcf>] ath_tx_complete_aggr+0x51f/0xb50 [ath9k]
[  754.095098]  [<ffffffffa05382a3>] ? ieee80211_prepare_and_rx_handle+0x173/0xab0 [mac80211]
[  754.095148]  [<ffffffff81350e62>] ? _raw_spin_unlock_irqrestore+0x32/0x40
[  754.095186]  [<ffffffffa02e9735>] ath_tx_tasklet+0x365/0x4b0 [ath9k]
[  754.095224]  [<ffffffff8107a2a2>] ? clockevents_program_event+0x62/0xa0
[  754.095261]  [<ffffffffa02e2628>] ath9k_tasklet+0x168/0x1c0 [ath9k]
[  754.095298]  [<ffffffff8105599b>] tasklet_action+0x6b/0xe0
[  754.095331]  [<ffffffff81056278>] __do_softirq+0x98/0x120
[  754.095361]  [<ffffffff8100cd5c>] call_softirq+0x1c/0x30
[  754.095393]  [<ffffffff8100efb5>] do_softirq+0x65/0xa0
[  754.095423]  [<ffffffff810563fd>] irq_exit+0x8d/0x90
[  754.095453]  [<ffffffff8100ebc1>] do_IRQ+0x61/0xe0
[  754.095482]  [<ffffffff81351413>] ret_from_intr+0x0/0x15
[  754.095513]  <EOI>
[  754.095531]  [<ffffffff81014375>] ? native_sched_clock+0x15/0x70
[  754.096475]  [<ffffffffa02bcfa6>] ? acpi_idle_enter_bm+0x24d/0x285 [processor]
[  754.096475]  [<ffffffffa02bcf9f>] ? acpi_idle_enter_bm+0x246/0x285 [processor]
[  754.096475]  [<ffffffff8127fab2>] cpuidle_idle_call+0x82/0x100
[  754.096475]  [<ffffffff8100a236>] cpu_idle+0xa6/0xf0
[  754.096475]  [<ffffffff81339bc1>] rest_init+0x91/0xa0
[  754.096475]  [<ffffffff814efccd>] start_kernel+0x3fd/0x408
[  754.096475]  [<ffffffff814ef347>] x86_64_start_reservations+0x132/0x136
[  754.096475]  [<ffffffff814ef451>] x86_64_start_kernel+0x106/0x115
[  754.096475] RIP  [<ffffffffa02eac49>] ath_tx_status+0x209/0x2f0 [ath9k]
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On hardware busy the scan request pointer should be cleared, as higher
levels will release. This avoids a crash when that pointer is
erroneously used later.
Signed-off-by: NJoseph J. Gunn <armadefuego@yahoo.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Clearly a mistake, since pointers won't suddenly
change their value...
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>