This reverts commit 7acc7c683a. It was
applied to avoid possible warning in ieee80211_restart_hw, however
reason of the warning were races in mac80211, currently hopefully fixed.
Not reseting device when performing scan is bad for two reasons.
When forcing reset from iwl_check_stuck_queue(), in case of fail,
reset will be repeated until scan finish. But since firmware is in bad
shape, scan only finish after scan_check work (about 7s). So we will
delay the reset, what is not good behaviour.
When forcing reset from iwl_recover_from_statistics(), we will not
repeat the reset, so we will not perform reset at all when needed.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John 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: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John 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: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John 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: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John 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: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John 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: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John 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: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John 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: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John 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: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John 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: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
wireless-testing
commit 37e5bf6535
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: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John 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: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Shu Hwa Shen <shensh@zcomm.com.cn>
Signed-off-by: John 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: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If kzalloc() fails then return should return with -ENOMEM.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: John 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: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John 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: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John 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: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John 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: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John 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: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John 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: Helmut Schaa <helmut.schaa@googlemail.com>
Reported-by: Lauri Hintsala <lauri.hintsala@bluegiga.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add the register definition CH_BUSY_STA_SEC for reading the busy time
on the secondary channel in HT40 mode. Also update the comments about
channel busy/idle time registers to express the used unit.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Make use of the IEEE80211_TX_RC_DUP_DATA flag to duplicate a
transmission with legacy rates to both 20Mhz channels if set.
Also update the related comment in rt2800.h to describe the
behavior of the BW_40 flag for legacy rates.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
During rx, rt2x00lib calls rt2800pci_fill_rxdone to read the RX
descriptor. At that time the skb is already dma unmapped but no new skb
was dma mapped for this entry again. However, rt2800pci_fill_rxdone also
moves the hw rx queue index, marking this entry to be available for
reuse. Since no new skb was dma mapped and also the previous skb was
unmapped this might lead to strange hw behavior.
To fix this issue move the hw rx queue index increment to
rt2800pci_clear_entry where a new skb was already dma mapped and can be
safely used by the hw.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since HT protection is now configurable via mac80211 we don't need this
special case for PCI devices anymore. The HT protection config will be
overwritten as soon as mac80211 sends us a HT operation mode. Hence,
bring the HT MM40 protection config in sync with the other HT protection
registers and initialize it to no protection.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Update the HT operation mode when mac80211 sends it to us and set
the different HT protection modes and rates accordingly. For now
only use CTS-to-self with OFDM 24M or CCK 11M when protection is
required.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix a check for dynamic SM PS mode in the STAs HT caps. Since a
value of 3 means "SM PS disabled" the previous check assumed in
that case that "dynamic SM PS" was enabled and as such prefixed
every MCS>7 frame with a unnecessary RTS/CTS exchange. Also,
the bit shift was done in the wrong direction.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch changes the way tx status reports are handled by rt2800pci.
Previously rt2800pci would sometimes lose tx status reports as the
TX_STA_FIFO register is a fifo of 16 entries that can overflow in case
we don't read it often/fast enough. Since interrupts are disabled in the
device during the execution of the interrupt thread it happend sometimes
under high network and CPU load that processing took too long and a few
tx status reports were dropped by the hw.
To fix this issue the TX_STA_FIFO register is read directly in the
interrupt handler and stored in a kfifo which is large enough to hold
all status reports of all used tx queues.
To process the status reports a new tasklet txstatus_tasklet is used.
Using the already used interrupt thread is not possible since we don't
want to disable the TX_FIFO_STATUS interrupt while processing them and
it is not possible to schedule the interrupt thread multiple times for
execution. A tasklet instead can be scheduled multiple times which
allows to leave the TX_FIFO_STATUS interrupt enabled while a previously
scheduled tasklet is still executing.
In short: All other interrupts are handled in the interrupt thread as
before. Only the TX_FIFO_STATUS interrupt is partly handled in the
interrupt handler and finished in the according tasklet.
One drawback of this patch is that it duplicates some code from
rt2800lib. However, that can be cleaned up in the future once the
rt2800usb and rt2800pci tx status handling converge more.
Using this patch on a Ralink RT3052 embedded board gives me a reliable
wireless connection even under high CPU and network load. I've
transferred several gigabytes without any queue lockups.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2800 devices use parts of the pariwise key table to store the beacon
frames for beacon 6 and 7. To not overwrite the beacon frame buffers
limit the number of entries we store in the pairwise key table to 222.
Also add some descriptive comments about this shared memory usage.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Includes pkts/bytes that may have had errors, and includes
wireless headers when counting bytes.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This adds counters for tx and rx bytes, including any
errored packets as well as all wireless headers.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Acked-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In the ath9k debugging feature 'wiphy' the current channel used by the
station is incorrectly displayed.This is because the channels available
are sequentially mapped from numbers 0 to 37.This mapping cannot be
changed as the channel number is also used as an array index
This fix solves the above problem by calculating the channel
number from center frequency.
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The percal struct and bitmask for the initial DC calibration are not
used anywhere, so they can be removed.
Signed-off-by: Felix Fietkau <nbd@openwrt.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since the regulatory code touches the channel array, it needs to be
copied for each device instance. That way the original channel array
can also be made const.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org [all]
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Support up to 4 virtual APs and as many virtual STA interfaces
as desired.
This patch is ported forward from a patch that Patrick McHardy
did for me against 2.6.31.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Acked-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We can start restarting firmware or RF kill switch can be turned on
during call to iwl_mac_add_interface(). That are normal working
conditions, so do not print call trace, just print simple message
instead.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The combined firmware ar9170.fw is preferred and supports all devices.
References to the older two-stage firmware are unnecessary.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
