Signed-off-by: NRafał Miłecki <zajec5@gmail.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>

Yikes! The error return keeps a netdev reference
and the rdev mutex locked, fix that!
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This adds API to allow adding per-station GTKs,
updates mac80211 to support it, and also allows
drivers to remove a key from hwaccel again when
this may be necessary due to multiple GTKs.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When roaming while we have active BA session,
we can end up transmitting delBA frames to
the old AP while we're already on the new AP's
channel, which can cause warnings.

Simply avoid sending those frames, but still
tear down the internal session state, since
they are not really necessary anyway as we
will implicitly disassociate when sending the
association to the new AP.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Acked-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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

drv_config callback is called only after the ack for the nullframe
is received and so driver need not do anything special for this.

So remove NULLFUNC_COMPLETED, PS_ENABLED flags and bf_isnullfunc
flags from ath9k as mac80211 already handles them properly.
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

After the last rounds of cleanup, these functions are now functionally
equivalent and can thus be merged.
Also get rid of some excessive (and redundant) debug messages.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The code gets more concise and readable when making the new ANI functions
fall back to the old ones if ANI v2 is disabled. This also makes further code
cleanup easier.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Split out the PHY error counter update from ath9k_hw_ani_monitor_*, reuse
it in ath9k_hw_proc_mib_event (merged from ath9k_hw_proc_mib_event_old
and ath9k_hw_proc_mib_event_new).
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ANI state is kept per channel, so instead of keeping an array of ANI states
with an arbitrary size of 255, move the ANI state into the channel struct.

Move some config settings that are not per-channel out of
the per-channel struct to save some memory.

With those changes, ath9k_ani_restart_old and ath9k_ani_restart_new can
be merged into a single function.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
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>

Throughout the code, DISABLE_REGWRITE_BUFFER is always called right after
REGWRITE_BUFFER_FLUSH. Since that's unlikely to change any time soon, that
makes keeping those ops separate rather pointless, as it only increases
code size and line number counts.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The cycle counters are used by ANI to determine the amount of time that the
radio spent not receiving or transmitting. They're also used for debugging
purposes if the baseband watchdog on AR9003 detects a lockup.
In the future, we want to use these counters to determine the medium utilization
and export this information via survey. For that, we need to make sure that
the counter is only accessed from one place, which also ensures that
wraparounds won't occur at inconvenient points in time.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The calibration actual calibration flags are only used by the per chip family
source files, so it makes more sense to define them in those files instead
of globally. That way the code has to test for less flags.

Also instead of using a separate callback for testing whether a particular
calibration type is supported, simply adjust ah->supp_cals in the calibration
init which is called right after the hardware reset, before any of the
calibrations are run.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We never delete the addBA response timer, which
is typically fine, but if the station it belongs
to is deleted very quickly after starting the BA
session, before the peer had a chance to reply,
the timer may fire after the station struct has
been freed already. Therefore, we need to delete
the timer in a suitable spot -- best when the
session is being stopped (which will happen even
then) in which case the delete will be a no-op
most of the time.

I've reproduced the scenario and tested the fix.

This fixes the crash reported at
http://mid.gmane.org/4CAB6F96.6090701@candelatech.com

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

  wireless-testing
  commit 37e5bf65
  Author: Luis R. Rodriguez <lrodriguez@atheros.com>
  Date:   Sat Jun 12 00:33:40 2010 -0400

    ath9k_hw: fix clock rate calculations for ANI

This commit accidentally broke clock rate calculation by doubling the
calculated clock rate
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Be consistent and use the wk->chan instead of the
local->hw.conf.channel for the association done work.
This prevents any possible races against channel changes
while we run this work.

In the case that the race did happen we would be initializing
the bit rates for the new AP under the assumption of a wrong
channel and in the worst case, wrong band. This could lead
to trying to assuming we could use CCK frames on 5 GHz, for
example.

This patch has a fix for kernels >= v2.6.34

Cc: stable@kernel.org
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The documentation for NL80211_CMD_REMAIN_ON_CHANNEL
isn't accurate, an interface index is required by
the command. Update it accordingly.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The base_eep_header_4k structure contains information that the
device supports high power tx gain table or not. However the
ath9k_hw_4k_get_eeprom function does not return that value when
it is called with EEP_TXGAIN_TYPE. This leads to that the tx gain
initialization will use the init values from the original tx gain
table even if the device inidicates that the high power table
should be used.

Changes-licensed-under: ISC
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NShu Hwa Shen <shensh@zcomm.com.cn>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We should only wake up queues which mac80211 knows about (queues 0-3). We have
another internal queue ("CAB", queue number 6) which we use for power-saved
frames. When transmitted frames are processed from this queue, we have to make
sure we don't bother mac80211 with waking a queue it doesn't know about.

this fixes:

WARNING: at /home/br1/ath/wireless-testing/net/mac80211/util.c:275
  __ieee80211_wake_queue+0xd6/0xe0 [mac80211]()
Signed-off-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The locking around ieee80211_recalc_smps is
buggy -- it cannot acquire another interface's
mutex while the iflist mutex is held because
another code path could be holding the iface
mutex and trying to acquire the iflist mutex.

But the locking is also unnecessary, we only
check "ifmgd->associated" as a bool, and don't
use the pointer (in check_mgd_smps).
Reported-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Consolidate boilerplate code needed for .dumpit
calls operating on netdevs.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use a new flag that requires the netdev to be
UP and use it to check instead of coding the
check into all functions that require it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This makes nl80211 use the new genetlink
pre_doit/post_doit hooks for locking and
checking the interface/wiphy index.

This significantly reduces the code size
and the likelihood of locking errors.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Each family may have some amount of boilerplate
locking code that applies to most, or even all,
commands.

This allows a family to handle such things in
a more generic way, by allowing it to
 a) include private flags in each operation
 b) specify a pre_doit hook that is called,
    before an operation's doit() callback and
    may return an error directly,
 c) specify a post_doit hook that can undo
    locking or similar things done by pre_doit,
    and finally
 d) include two private pointers in each info
    struct passed between all these operations
    including doit(). (It's two because I'll
    need two in nl80211 -- can be extended.)
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If kzalloc() fails then return should return with -ENOMEM.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Enable WME QoS in IBSS mode by adding a WME information element to beacons and
probe respones and by checking for it and marking stations as WME capable if it
is present.
Signed-off-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If a frame is not meant to be sent as AMPDU or part of it the hw might
still decide to aggregate this frame if a previous frame started an
AMPDU. However, this will limit the usefulness of the reported tx rate
since the reported rate will be the one specified in the TXWI of the
first frame and thus it is not possible to reliably caculate the
number of retrys by substracting the reported tx rate from the tx rate
in the TXWI.

To fix this issue, only report the successful rate for frames that were
not meant to be aggregated but ended up in an aggregate.

Example:
Frame A (MCS7, AMPDU=1) B (MCS7, AMPDU=1) C (MCS12, AMDPU=0, PROBE_RATE)

Although frame C shoudn't be aggregated the hw might sill put it
into an AMPDU together with A and B. If the transmission succeeds the tx
status will contain MCS7 for all three frames. In that case we should
only report MCS7 as success rate and avoid reporting MCS12-MCS8 as
failed tx attempts as this will affect the future rate control
decisions.

This oddity might strike us in other scenarious as well but the most
common "wrong" report happened for frames used to probe a different tx
rate.

This improves the rate control decisions notable.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In order to lower the impact of probe rates don't send a frame as AMPDU
if the rate control algorithm sets IEEE80211_TX_CTL_RATE_CTRL_PROBE.
Otherwise a whole aggregate would be send with a probe rate which might
lead to numerous retries.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When rt2x00lib_enable_radio fails to enable the radio, rt2x00lib_start
will call rt2x00queue_uninitialize to uninitialize the queues. Since,
the queues are not initialized here but already in rt2x00lib_initialize
we shouldn't uninitialize the queues here. Otherwise, a consecutive call
to rt2x00lib_start will oops (see below) because it assumes the queues
are already initialized.

BUG: unable to handle kernel NULL pointer dereference at 00000010
IP: [<f8d2d901>] :rt2800pci:rt2800pci_clear_entry+0x1/0x40
*pde = 00000000
Oops: 0000 [#1] SMP
Modules linked in: ... rt2800pci ...

Pid: 5995, comm: hostapd Not tainted (2.6.27.8 #1)
EIP: 0060:[<f8d2d901>] EFLAGS: 00210246 CPU: 3
EIP is at rt2800pci_clear_entry+0x1/0x40 [rt2800pci]
EAX: 00000000 EBX: f698863c ECX: 00200296 EDX: f8d2dee0
ESI: f6988600 EDI: f5b6f000 EBP: 00000000 ESP: f6d75e4c
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process hostapd (pid: 5995, ti=f6d74000 task=f6ce2300 task.ti=f6d74000)
Stack: f698863c fa00eaec 00000000 f5b6f000 00000000 f7b67000 f5b6e280 fa00c629
      f5b6f000 00000000 fa00ca3d f7b67480 00000001 fa177d4c 01b6e890 f7b67000
      00000000 f7b67000 00000001 00001003 00001002 c066c366 f7b67000 c0668ad0
Call Trace:
 [<fa00eaec>] rt2x00queue_init_queues+0x5c/0x90 [rt2x00lib]
 [<fa00c629>] rt2x00lib_enable_radio+0x29/0xa0 [rt2x00lib]
 [<fa00ca3d>] rt2x00lib_start+0x5d/0xd0 [rt2x00lib]
 [<fa177d4c>] ieee80211_do_open+0x21c/0x510 [mac80211]
 [<c066c366>] dev_open+0x56/0xb0
 [<c0668ad0>] dev_set_rx_mode+0x20/0x40
 [<c066a67f>] dev_change_flags+0x7f/0x190
 [<c06b1495>] devinet_ioctl+0x515/0x690
 [<c0668d24>] __dev_get_by_name+0x74/0x90
 [<c065d3f0>] sock_ioctl+0xd0/0x240
 [<c065d320>] sock_ioctl+0x0/0x240
 [<c018179b>] vfs_ioctl+0x2b/0x90
 [<c0181a5b>] do_vfs_ioctl+0x25b/0x2a0
 [<c0181af6>] sys_ioctl+0x56/0x70
 [<c0103262>] syscall_call+0x7/0xb
 [<c0700000>] add_card+0xad0/0xba0
 =======================
Code: 83 78 08 0e 74 14 8b 02 8b 48 04 85 c9 0f 99 c0 0f b6 c0 c3 8d b6
      00 00 00 00 8b 02 8b 40 04 85 c0 0f 99 c0 0f b6 c0 c3 66 90 53 <8b>
      48 10 8b 58 08 8b 40 04 83 78 08 0e 74 15 8b 11 83 c2 04 8b
EIP: [<f8d2d901>] rt2800pci_clear_entry+0x1/0x40 [rt2800pci] SS:ESP 0068:f6d75e4c
---[ end trace cff9a5c094bb8837 ]---
Reported-by: NJoshua Smith <jesmith@kaon.com>
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

During testing with AMPDUs it turned out that the rt2800 hw will aggregate
consecutive frames with the same RA and TID when the first frame in a
possible aggregate has set AMPDU=1 in the TXWI. If a following frame has
set AMPDU=0 in its TXWI it might sill end up in the aggregate of the
previous frame. Update the comment accordingly.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The TX_STA_FIFO contains some information for identifying
a outgoing frame, however matching by WCID and ACK status is
not sufficient to 100% identify the macthing queue_entry structure
(containing the SKB buffer) which belongs to the status report.

Within TX_STA_FIFO we have a 4-bit field named PACKETID, which is
currently used to encode the queue id. The queue ID is however
limited to values from 0 to 3, which means 2 bits are sufficient
to encode the value. With the remaining 2 bits we can encode a
partial queue_entry index number. The value of PACKETID is not
allowed to become 0, with the queue ID ranging from 0 to 3, at least
one of the bits for the entry identification must be 1.

That leaves us with 3 possible values we can still encode in the
bits. Altough this doesn't allow 100% accurate matching of the
TX_STA_FIFO queue to a queue_entry structure, it at least improves
the accuracy. This allows us to better detect if we have missed the
TX_STA_FIFO report, which in turn reduces the number of watchdog
warnings regarding the TX status timeout.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rt61pci and rt2800 devices can use up to 7 different rates per tx frame.
However, the device uses a global fallback table. Hence, the rc
algortihm cannot specify multiple rates to try but the device is able to
report multiple rates (based on the retry table). Specify that behavior
by correctly setting max_report_rates and max_rates.

This makes rt2x00 and minstrel play nicer together.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some drivers cannot handle multiple retry rates specified by the rc
algorithm but instead use their own retry table (for example rt2800).
However, if such a device registers itself with a max_rates value of 1
the rc algorithm cannot make use of the extended information the device
can provide about retried rates. On the other hand, if a device
registers itself with a max_rates value > 1 the rc algorithm assumes
that the device can handle multi rate retries.

Fix this issue by introducing another hw parameter max_report_rates that
can be set to a different value then max_rates to indicate if a device
is capable of reporting more rates then specified in max_rates.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since rt2x00 USB devices have no chance to know when a beacon was sent
out in AP mode currently all broad- and multicast traffic is buffered in
mac80211 but never sent out at all.

Unfortunately we have no chance in sending the traffic out after a
DTIM beacon due to hw limitations. Hence, instead of never sending the
buffered traffic out better send it out immediately.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Reported-by: NLauri Hintsala <lauri.hintsala@bluegiga.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>