AR_RxKeyIdxValid will not be set for bcast/mcast frames and so relying
this status for MIC failed frames is buggy.

Due to this, MIC failure events for broadcast frames are not sent to
supplicant resulted in AP disconnecting the STA.

Able to pass Wifi Test case 5.2.18 with this fix.

Cc: Stable <stable@kernel.org> (2.6.36+)
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

while removing beaconing mode interface, SWBA interrupt
was never disabled when there are no other beaconing interfaces.

Cc: stable@kernel.org
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

With some upcoming changes we'd like to use
the interface types for P2P capability tests.
Enable them now so that when we add those
tests in wpa_supplicant, nothing will break.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The ath9k driver uses a shared pm_qos_request_list structure for all
devices. This causes the following warning if more than one device is
present in the system:

WARNING: at kernel/pm_qos_params.c:234 ath9k_init_device+0x5e8/0x6b0()
pm_qos_add_request() called for already added request
Modules linked in:
Call Trace:
[<802b1cdc>] dump_stack+0x8/0x34
[<8007dd90>] warn_slowpath_common+0x78/0xa4
[<8007de44>] warn_slowpath_fmt+0x2c/0x38
[<801b0828>] ath9k_init_device+0x5e8/0x6b0
[<801bc508>] ath_pci_probe+0x2dc/0x39c
[<80176254>] pci_device_probe+0x64/0xa4
[<8019471c>] driver_probe_device+0xbc/0x188
[<80194854>] __driver_attach+0x6c/0xa4
[<80193e20>] bus_for_each_dev+0x60/0xb0
[<80193580>] bus_add_driver+0xcc/0x268
[<80194c08>] driver_register+0xe0/0x198
[<801764e0>] __pci_register_driver+0x50/0xe0
[<80365f48>] ath9k_init+0x3c/0x6c
[<8006050c>] do_one_initcall+0xfc/0x1d8
[<80355340>] kernel_init+0xd4/0x174
[<800639a4>] kernel_thread_helper+0x10/0x18

---[ end trace 5345fc6f870564a6 ]---

This patch fixes that warning by using a separate pm_qos_request_list
sructure for each device.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It seems that using ath9k_hw_stoppcurecv to stop rx dma is not enough.
When it's time to stop DMA, the PCU is still busy, so the rx enable
bit never clears.
Using ath9k_hw_abortpcurecv helps with getting rx stopped much faster,
with this change, I cannot reproduce the rx stop related WARN_ON anymore.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Setting tid information in the TX header is required only for QoS
frames. Not handling this case causes severe data loss with some APs.

Cc: stable@kernel.org
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

AR9287 based PCI & USB devices are differed in eeprom start offset.
So set proper the offset for HTC devices to read nvram correctly.

Cc: stable@kernel.org
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Treat new PIDs (0xA704, 0x1200) as AR7010 devices.

Cc: stable@kernel.org
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Added new VID/PIDs into supported devices list

Cc: stable@kernel.org
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Update pm_qos before removing it in deinit_device to prevent this
warning:

pm_qos_update_request() called for unknown object.
Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The allocated externel radio banks have to be freed in
case of ath9k_hw_rf_alloc_ext_banks failure.

Cc: stable@kernel.org
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since the endpoint descriptors (EP3 & EP4) were changed from Interrupt
to Bulk type by firmware, the urb submission done on Bulk pipes.
And the recent commit "check the endpoint type against the pipe type"
added aditional error checking against pipe types under CONFIG_USB_DEBUG.

So bmAttribute has to be updated for both EP3 & EP4 before submitting
urbs on that pipe. This patch resolves the following failure.

[ 2215.710936] usb 1-1: usb_probe_device
[ 2215.710945] usb 1-1: configuration #1 chosen from 1 choice
[ 2215.711152] usb 1-1: adding 1-1:1.0 (config #1, interface 0)
[ 2215.711252] ath9k_hif_usb 1-1:1.0: usb_probe_interface
[ 2215.711255] ath9k_hif_usb 1-1:1.0: usb_probe_interface - got id
[ 2215.712780] usb 1-1: BOGUS urb xfer, pipe 3 != type 1
[ 2215.713782] usb 1-1: ath9k_htc: Unable to allocate URBs
[ 2215.713801] ath9k_hif_usb: probe of 1-1:1.0 failed with error -22
Reported-by: NMing Lei <tom.leiming@gmail.com>
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch adds support for USB dongle with device ID 3346 from IMC Networks.
Signed-off-by: NHaitao Zhang <minipanda@linuxrobot.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Bit 22 of AR_WA should be set to fix the situation where chip reset
is asynchronous to clock of analog shift registers, such that when
reset is released, it could mess up the values of analog shift registers
and cause some hw issue on AR9280.

This bit is write only, but the driver does a read-modify-write
on AR_WA without setting bit 22 in ar9002_hw_configpcipowersave()
during radio disable. This causes surprise removal of hw. It can
never recover from this state and the hw will become usable only
after a power on/off cycle, and sometimes only during a cold reboot.

This issue can be triggered by doing frequent roaming with the
simple/test-roam script available from the wifi-test project [1]
when roaming between APs quickly. When roaming there is a is a high
possibility that the device being put into idle (radio disable) state
by mac80211 during AUTH->ASSOC. A device hardware reset would fail
and the kernel would output:

[40251.363799] ath: AWAKE -> FULL-SLEEP
[40251.363815] ieee80211 phy17: device no longer idle - working
[40251.363817] ath: Marking phy17 as not-idle
[40251.363819] ath: FULL-SLEEP -> AWAKE
[40251.415978] pciehp 0000:00:1c.3:pcie04: Card not present on Slot(3)
[40251.419896] ath: ah->misc_mode 0x4
[40251.428138] pciehp 0000:00:1c.3:pcie04: Card present on Slot(3)
[40251.532247] ath: timeout (100000 us) on reg 0x9860: 0xffffffff & 0x00000001 != 0x00000000
[40251.532250] ath: Unable to reset channel (2462 MHz), reset status -5
[40251.532422] ath: Set channel: 5745 MHz
[40251.540639] ath: Failed to stop TX DMA in 100 msec after killing last frame
[40251.548826] ath: Failed to stop TX DMA in 100 msec after killing last frame
[40251.557023] ath: Failed to stop TX DMA in 100 msec after killing last frame
[40251.565211] ath: Failed to stop TX DMA in 100 msec after killing last frame
[40251.573415] ath: Failed to stop TX DMA in 100 msec after killing last frame
[40251.581603] ath: Failed to stop TX DMA in 100 msec after killing last frame
[40251.581606] ath: Failed to stop TX DMA. Resetting hardware!
[40251.592679] ath: DMA failed to stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff
[40251.703330] ath: timeout (100000 us) on reg 0x7000: 0xffffffff & 0x00000003 != 0x00000000
[40251.703333] ath: RTC stuck in MAC reset
[40251.703334] ath: Chip reset failed
[40251.703335] ath: Unable to reset hardware; reset status -22

This is currently only reproducible with some HB92 (Half Mini-PCIE)
cards but the fix applies to all AR9280 cards. This patch fixes this
issue by setting bit 22 during radio disable.

This patch has fixes for all kernels that has ath9k.

[1] http://wireless.kernel.org/en/developers/Testing/wifi-test

Cc: kyungwan.nam@atheros.com
Cc: amod.bodas@atheros.com
Cc: david.quan@atheros.com
Cc: stable@kernel.org
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ath9k_ps_wakeup() clears the cycle counters after waking up the
hardware using ath9k_hw_setpower, however if power save is disabled,
then the counters will contain useful data, which then gets discarded.
Fix this by checking the old power mode before discarding any data.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Throughput was severely affected in Intel Pinetrail platforms
because of a DMA problem in C3 state. This patch fixes this
issue.
Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com>
CC: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The HW opmode is blindly set to monitor type on monitor mode
change notification. This overrides the opmode when one of the
interfaces is still running as non-monitor iftype. So the monitoring
information needs to be maintained seperately.
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The index variable to access the rate flags should be obtained from the
inner loop counter which corresponds to the rate table structure.This
fixes the invalid rate selection i.e when the supported basic rate is
invalid on a particular band and also the following warning message.
Thanks to Raj for finding this out.

Call Trace:

 [<ffffffff8104ee4a>] warn_slowpath_common+0x7a/0xb0

 [<ffffffff8104ee95>] warn_slowpath_null+0x15/0x20

 [<ffffffffa0583c45>] ath_get_rate+0x595/0x5b0 [ath9k]

 [<ffffffff811a0636>] ? cpumask_next_and+0x36/0x50

 [<ffffffffa0405186>] rate_control_get_rate+0x86/0x160 [mac80211]

 [<ffffffffa040dfac>] invoke_tx_handlers+0x81c/0x12d0 [mac80211]

 [<ffffffffa040eae9>] ieee80211_tx+0x89/0x2b0 [mac80211]

 [<ffffffff812891bc>] ? pskb_expand_head+0x1cc/0x1f0

 [<ffffffffa040edc5>] ieee80211_xmit+0xb5/0x1c0 [mac80211]

 [<ffffffffa041026f>] ieee80211_tx_skb+0x4f/0x60 [mac80211]

 [<ffffffffa03fe016>] ieee80211_send_nullfunc+0x46/0x60 [mac80211]

 [<ffffffffa03f91d7>] ieee80211_offchannel_stop_station+0x107/0x150
[mac80211]

 [<ffffffff812891bc>] ? pskb_expand_head+0x1cc/0x1f0

 [<ffffffffa040edc5>] ieee80211_xmit+0xb5/0x1c0 [mac80211]

 [<ffffffffa041026f>] ieee80211_tx_skb+0x4f/0x60 [mac80211]

 [<ffffffffa03fe016>] ieee80211_send_nullfunc+0x46/0x60 [mac80211]

 [<ffffffffa03f91d7>] ieee80211_offchannel_stop_station+0x107/0x150
[mac80211]

 [<ffffffffa03f8896>] ieee80211_scan_work+0x146/0x600 [mac80211]

 [<ffffffff8133a375>] ? schedule+0x2f5/0x8e0

 [<ffffffffa03f8750>] ? ieee80211_scan_work+0x0/0x600 [mac80211]

 [<ffffffff81064fcf>] process_one_work+0x10f/0x380

 [<ffffffff81066bc2>] worker_thread+0x162/0x340

 [<ffffffff81066a60>] ? worker_thread+0x0/0x340

Cc: stable@kernel.org
Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Netgear WNDA3200 device uses ar7010 firmware but it is failed to set
correct firmware offset on firmware download which causes device initialization
failure.

Cc: stable@kernel.org
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Completing aggregate frames can lead to new buffers being pushed into
the tid queues due to software retransmission.
When the tx queues are being drained, all pending aggregates must be
completed before the tid queues get drained, otherwise buffers might be
leaked.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Apart from locking the start and stop PCU we need
to ensure we also content starting and stopping the PCU
between hardware resets.

This is part of a series that will help resolve the bug:

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

For more details about this issue refer to:

http://marc.info/?l=linux-wireless&m=128629803703756&w=2

Cc: stable@kernel.org
Cc: Ben Greear <greearb@candelatech.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Tested-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The real way to lock RX is to contend on the PCU
and reset, this will be fixed in the next patch but for
now just do the renames so that the next patch which changes
the locking order is crystal clear.

This is part of a series that will help resolve the bug:

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

For more details about this issue refer to:

http://marc.info/?l=linux-wireless&m=128629803703756&w=2

Cc: stable@kernel.org
Cc: Ben Greear <greearb@candelatech.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Tested-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There was some locking for starting some parts of
RX but not for starting the PCU. Include this otherwise
we can content against stopping the PCU.

This can potentially lead to races against different
buffers on the PCU which can lead to to the DMA RX
engine writing to buffers which are already freed.

This is part of a series that will help resolve the bug:

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

For more details about this issue refer to:

http://marc.info/?l=linux-wireless&m=128629803703756&w=2

Cc: stable@kernel.org
Cc: Ben Greear <greearb@candelatech.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Tested-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ath9k locks for starting RX but not for stopping RX. We could
potentially run into a situation where tried to stop RX
but immediately started RX. This allows for races on the
the RX engine deciding what buffer we last left off on
and could potentially cause ath9k to DMA into already
free'd memory or in the worst case at a later time to
already given memory to other drivers.

Fix this by locking stopping RX.

This is part of a series that will help resolve the bug:

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

For more details about this issue refer to:

http://marc.info/?l=linux-wireless&m=128629803703756&w=2

Cc: stable@kernel.org
Cc: Ben Greear <greearb@candelatech.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Tested-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since aggregation is usually triggered by tx completion, a hardware
reset (because of beacon stuck, tx hang or baseband hang) can
significantly delay the transmission of the next AMPDU (until the next
tx completion event).
Fix this by rescheduling aggregation after such a reset.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The ath9k aggregation code was already checking the rate control probe flag
to prevent starting an aggregate frame with a sampling rate. What was missing
was closing an aggregate before adding a probing frame to it.
Without that, rate control cannot have precise control over probing, which
delays using faster rates when the channel conditions improve.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If ah->curchan is uninitialized, the channel index is bogus, which leads
to invalid memory access when the cycle counters are updated.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We are not handling all divide by zero cases in paprd.
Add additional checks for divide by zero cases in papard.

This patch has fixes intended for kernel 2.6.36.

Cc: stable@kernel.org
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This updates the initvals for the AR9003 2.2 chipsets. The initvals
are the initial register values we use for our registers upon hardware
reset. This synchs up the initvals to match what our latest recommendation
from our systems engineering team.

The description of changes in this update:

        Improves ability to support very strong Rx conditions.
        Enhances DFS support for AP-mode.
        Improves performance of Tx carrier leak calibration.
        Adds support for Japan channel 14 Tx filtering requirements.
        Improves Tx power accuracy.

Impact:

        Update required to address degraded throughput at very short range.
        Update required for AP-mode DFS certification.
        Update required to comply to IEEE Tx carrier leak specification.
        May not meet expected +/- 2 dB Tx power accuracy without update.

The most important fix here would be the TX carrier leakage required
to comply with IEEE 802.11 specifications. The group of changes have
been tested all together in one release.

References:

	Osprey 2.2 header file ver #33

Checksums:

$ ./initvals -f ar9003-2p2
0x000000004a488fc7        ar9300_2p2_radio_postamble
0x0000000046cb1300        ar9300Modes_lowest_ob_db_tx_gain_table_2p2
0x00000000e912711f        ar9300Modes_fast_clock_2p2
0x0000000037ac0ee8        ar9300_2p2_radio_core
0x00000000047a7700        ar9300Common_rx_gain_table_merlin_2p2
0x0000000003f783bb        ar9300_2p2_mac_postamble
0x00000000301fc841        ar9300_2p2_soc_postamble
0x000000005ec8075f        ar9200_merlin_2p2_radio_core
0x0000000083372ffa        ar9300_2p2_baseband_postamble
0x00000000c4f59974        ar9300_2p2_baseband_core
0x00000000e20d2e72        ar9300Modes_high_power_tx_gain_table_2p2
0x000000007fd55c70        ar9300Modes_high_ob_db_tx_gain_table_2p2
0x0000000029495000        ar9300Common_rx_gain_table_2p2
0x0000000042cb1300        ar9300Modes_low_ob_db_tx_gain_table_2p2
0x00000000c4739cd6        ar9300_2p2_mac_core
0x000000003521a300        ar9300Common_wo_xlna_rx_gain_table_2p2
0x00000000a15ccf1b        ar9300_2p2_soc_preamble
0x0000000029734396        ar9300PciePhy_pll_on_clkreq_disable_L1_2p2
0x000000002d834396        ar9300PciePhy_clkreq_enable_L1_2p2
0x0000000029834396        ar9300PciePhy_clkreq_disable_L1_2p2

$ ./initvals -f ar9003-2p2 | sha1sum
0ceddb5cf66737610fb51f04cf3e9ff71870c7b4  -

Cc: stable@kernel.org
Cc: Yixiang Li <yixiang.li@atheros.com>
Cc: Don Breslin <don.breslin@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Otherwise, lockdep splats, at the least:

INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
Pid: 2240, comm: ip Not tainted 2.6.36-rc8-wl+ #32
Call Trace:
 [<c075d940>] ? printk+0xf/0x17
 [<c045507a>] register_lock_class+0x5a/0x29e
 [<c0455be2>] ? mark_lock+0x1e/0x1de
 [<c0456af5>] __lock_acquire+0xa2/0xb8c
 [<c0455be2>] ? mark_lock+0x1e/0x1de
 [<c0457639>] lock_acquire+0x5a/0x78
 [<f8c5115b>] ? ath9k_config+0x274/0x3d8 [ath9k]
 [<c075f602>] _raw_spin_lock_irqsave+0x2f/0x3f
 [<f8c5115b>] ? ath9k_config+0x274/0x3d8 [ath9k]
 [<f8c5115b>] ath9k_config+0x274/0x3d8 [ath9k]
 [<f8c0ba2e>] ieee80211_hw_config+0x11b/0x125 [mac80211]
 [<f8c17edf>] ieee80211_do_open+0x3c5/0x466 [mac80211]
 [<f8c171d6>] ? ieee80211_check_concurrent_iface+0x21/0x13a [mac80211]
 [<f8c17fdb>] ieee80211_open+0x5b/0x5e [mac80211]
 [<c06ce76b>] __dev_open+0x80/0xae
 [<c06cc99b>] __dev_change_flags+0xa0/0x115
 [<c06ce6bf>] dev_change_flags+0x13/0x3f
 [<c06d7e78>] do_setlink+0x23a/0x51b
 [<c0455037>] ? register_lock_class+0x17/0x29e
 [<c06d847c>] rtnl_newlink+0x269/0x431
 [<c06d8291>] ? rtnl_newlink+0x7e/0x431
 [<c0455be2>] ? mark_lock+0x1e/0x1de
 [<c0455de9>] ? mark_held_locks+0x47/0x5f
 [<c075ebcf>] ? __mutex_lock_common+0x2bb/0x2d6
 [<c0456045>] ? trace_hardirqs_on_caller+0x104/0x125
 [<c075ebe0>] ? __mutex_lock_common+0x2cc/0x2d6
 [<c06d8213>] ? rtnl_newlink+0x0/0x431
 [<c06d79e2>] rtnetlink_rcv_msg+0x182/0x198
 [<c06d7860>] ? rtnetlink_rcv_msg+0x0/0x198
 [<c06e503c>] netlink_rcv_skb+0x30/0x77
 [<c06d7859>] rtnetlink_rcv+0x1b/0x22
 [<c06e4e77>] netlink_unicast+0xbe/0x119
 [<c06e5a15>] netlink_sendmsg+0x234/0x24c
 [<c06bf93a>] __sock_sendmsg+0x51/0x5a
 [<c06bfba4>] sock_sendmsg+0x93/0xa7
 [<c04968cf>] ? might_fault+0x47/0x81
 [<c0496904>] ? might_fault+0x7c/0x81
 [<c06c7904>] ? copy_from_user+0x8/0xa
 [<c06c7c2d>] ? verify_iovec+0x3e/0x6d
 [<c06bfd8c>] sys_sendmsg+0x149/0x193
 [<c0455037>] ? register_lock_class+0x17/0x29e
 [<c0455be2>] ? mark_lock+0x1e/0x1de
 [<c0498d7a>] ? __do_fault+0x1fc/0x3a5
 [<c048690a>] ? unlock_page+0x40/0x43
 [<c0498ef7>] ? __do_fault+0x379/0x3a5
 [<c04576dd>] ? lock_release_non_nested+0x86/0x1d8
 [<c04968cf>] ? might_fault+0x47/0x81
 [<c04968cf>] ? might_fault+0x47/0x81
 [<c06c148b>] sys_socketcall+0x15e/0x1a5
 [<c0402f1c>] sysenter_do_call+0x12/0x38
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This doesn't fix any problem that I'm aware of, but should
make it harder to add use-after-free type bugs in the
future.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The bf_dmacontext seems to be totally useless and duplicated
by bf_buf_addr.  Remove it entirely, use bf_buf_addr in its
place.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

These chipsets will not hit the market, all customers will be
on >= AR9003 2.2. This shaves down the ath9k_hw size by
24161 bytes (24 KB) on my system.

Before:

$ size drivers/net/wireless/ath/ath9k/ath9k_hw.ko
   text	   data	    bss	    dec	    hex	filename
 292328	    616	   1824	 294768	  47f70	drivers/net/wireless/ath/ath9k/ath9k_hw.ko

$ du -b drivers/net/wireless/ath/ath9k/ath9k_hw.ko
5987825	drivers/net/wireless/ath/ath9k/ath9k_hw.ko

After:

$ size drivers/net/wireless/ath/ath9k/ath9k_hw.ko
   text	   data	    bss	    dec	    hex	filename
 277192	    616	   1824	 279632	  44450	drivers/net/wireless/ath/ath9k/ath9k_hw.ko

$ du -b drivers/net/wireless/ath/ath9k/ath9k_hw.ko
5963664	drivers/net/wireless/ath/ath9k/ath9k_hw.ko

Cc: Yixiang Li <yixiang.li@atheros.com>
Cc: Don Breslin <don.breslin@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch enables to receive probe request frames on p2p
client mode.
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The wireless mode bitfield was only used to detect 2.4 and 5 GHz support,
which can be simplified by using ATH9K_HW_CAP_* capabilities.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Set the rate table in the rc module properly based on band and
HT capabilities instead, which was already partially done, but
not for every mode.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Move them to the same debugfs file that the other rc modules use.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ath9k_hw_proc_mib_event updates the cycle counters, so it common->cc_lock
must be acquired.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

PHY counter overflows need to be checked for the old ANI version,
because of its use of interrupt based counter overflow reports when
the counters exceed the configured thresholds.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The commit "ath9k_hw: remove code duplication in phy error counter handling"
split off some duplicate code into a separate function, but did not have a
return code for aborting ANI processing based on counter values.
This introduced a divide by zero issue.
This patch adds the missing return code check in ath9k_hw_ani_monitor
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>