The new PCU lock is better placed so we can just contend
against that when trying to reset hardware.

This is part of a series of patches which fix stopping
TX DMA completley when requested on the driver.
For more details about this issue refer to this thread:

http://marc.info/?l=linux-wireless&m=128629803703756&w=2Tested-by: NBen Greear <greearb@candelatech.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Cc: stable@kernel.org
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This takes care that boolean types are properly assigned
Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

No need to inform about monitor interface changes to
firmware. Set the HW mode to monitor type based on mac80211
indication flag is sufficient.
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

According to documentation, AR_ExcessiveRetries, AR_Filtered and
AR_FIFOUnderrun are only valid if AR_FrmXmitOK is clear.

Not checking this might result in suboptimal FIFO settings, unnecessary
retransmissions, or other connectivity issues.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We have seen several DMA races when we race against
stopping and starting the PCU. I suspect that when
we cannot stop the PCU we may hit some of these same
races so warn against them for now but only when
debugging (CONFIG_ATH_DEBUG) is enabled.

If you run into this warning and are a developer,
please fix the cause of the warning. The potential
here, although I cannot prove yet, is that the DMA
engine can be confused and start writing to a buffer
that was already DMA'd before and at least the kernel
assumes is not being accessed by hardware anymore.

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

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

ath9k_hw_set_txpowerlimit gets an extra boolean parameter that - if set -
causes the rate txpower table and the regulatory limit to be calculated
and stored, without changing hardware registers.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The same is done for the older chip families as well.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

With the current rate control selection method the median function is
nowhere used, so remove it.
Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Because all of the descriptor data structures are marked as __packed, GCC
assumes the worst case wrt. alignment and generates unaligned load/store
instructions on MIPS for access to all fields.
Since descriptors always have to be 4-byte-aligned, we can just mark the
data structures with __aligned(4), which allows GCC to generate much more
efficient code.
Verified through disassembly and OProfile comparisons.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The ath9k driver uses the legacy PCI power management (suspend
and resume) callbacks that apparently cause intermittent problems
to happen (the adapter sometimes doesn't resume correctly on my
Acer Ferrari One).  Make it use the new PCI PM and let the PCI core
code handle the PCI-specific details of power transitions.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This fixes this sparse complaint:

  CHECK   drivers/net/wireless/ath/ath9k/debug.c
drivers/net/wireless/ath/ath9k/debug.c:548:34: warning: symbol 'aphy' shadows an earlier one
drivers/net/wireless/ath/ath9k/debug.c:491:26: originally declared here
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It is now only used in hw.c
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When the timer_next argument to ath9k_gen_timer_start is behind the tsf value,
tsf + timer_period is used, which is what ath_btcoex_period_timer was setting
it to.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ANI needs the RSSI average only in station mode, and only for tracking
the signal strength of beacons of the AP that it is connected to.
Adjust the code to track on the beacon RSSI, and store the average of that
in the ath_wiphy struct.
With these changes, we can get rid of this extra station lookup in the
rx path, which saves precious CPU cycles.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Disassembly shows, that at least on MIPS, the compiler generates a lot of
memory accesses to the same location in the descriptor field parsing.
Since it is operating on uncached memory, this can be quite expensive in
this hot path.
Change the code a bit to help the compiler optimize it properly, and get
rid of some unused fields in the ath_tx_status struct.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ah->config.rx_intr_mitigation does not need to be checked before checking
the rx interrupt mask for AR_ISR_RXMINTR or AR_ISR_RXINTM, as those
interrupts will be masked out if rx interrupt mitigation is disabled.

Avoid reading AR_ISR_S5_S twice by reordering the code to be more concise.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

OProfile showed that ath9k was spending way too much time in
ath9k_hw_set_interrupts. Since most of the interrupt mask changes only
need to globally enable/disable interrupts, it makes sense to split
this part into separate functions, replacing all calls to
ath9k_hw_set_interrupts(ah, 0) with ath9k_hw_disable_interrupts(ah).

ath9k_hw_set_interrupts(ah, ah->imask) only gets changed to
ath9k_hw_enable_interrupts(ah), whenever ah->imask was not changed
since the point where interrupts were disabled.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
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>