Jumbo frames are not supported, and if they are seen it is likely
a bogus frame so just silently discard them instead of warning on
them all time. Also, instead of dropping them immediately though
move the check *after* we check for all sort of frame errors. This
should enable us to discard these frames if the hardware picks
other bogus items first. Lets see if we still get those jumbo
counters increasing still with this.
Jumbo frames would happen if we tell hardware we can support
a small 802.11 chunks of DMA'd frame, hardware would split RX'd
frames into parts and we'd have to reconstruct them in software.
This is done with USB due to the bulk size but with ath5k we
already provide a good limit to hardware and this should not be
happening.
This is reported quite often and if it fills the logs then this
needs to be addressed and to avoid spurious reports.
Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There are several places that use > ARRAY_SIZE() instead of
>= ARRAY_SIZE().
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
I changed "> ATH9K_HTC_MAX_TID" to ">= ATH9K_HTC_MAX_TID" to avoid a
potential overflow.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is a stray null dereference. We initialize "ista" properly later on.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Paul Shaw <paul.shaw@atheros.com>
Cc: Don Breslin <don.breslin@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Switch LED off/on when handling CONF_CHANGE_IDLE.
Not doing this would leave the radio LED on even
though the chip would be in full sleep mode.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_common (used by ath9k and ath9k_htc) trusts the frames
blessed by hardware as OK are infact correct even if the rate
seen by the driver is unrecognized. ath9k_common just treats
these frames in mac80211 as frames as frames under 1 mbps rate.
It seems this might not be the best thing to do as other parts of
the frame might not be valid so just drop these frames for now.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This has no real functional change, this just moves the setting the
the mac80211 rate index into ath9k_process_rate(). This allows us
to eventually make ath9k_process_rate() return a negative value
in case we have detected a specific case rate situation which should
have been ignored.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The current way of managing beaconing in ad-hoc
mode has a subtle race - the beacon obtained from mac80211
is freed in the SWBA handler rather than the TX
completion routine. But transmission of beacons goes
through the normal SKB queue maintained in hif_usb,
leading to a situation where __skb_dequeue() in the TX
completion handler goes kaput.
Fix this by simply getting a beacon from mac80211 for
every SWBA and free it in its completion routine.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Atheros hardware supports receiving frames that span multiple
descriptors and buffers. In this case, the rx status of every
descriptor except for the last one is invalid and may contain random
data. Because the driver does not support this, it needs to drop such
frames.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch removes the incomplete AMPDU implementation in ar9170usb.
The code in question is:
* too big and complex (more than 550 SLOC.)
This is enough to qualify for a new separate code file!
* unbalanced quantity & quality
over-engineered areas like:
* xmit scheduling and queuing frames for multiple HT peers
* redundant frame sorting
are confronted by gaping holes:
* accurate transmission feedback
* firmware error-handling and device reset
* HT rate control algorithm
* error-prone
Since its inclusion, hardly anything was done to fix
any of the outlined flaws from the initial commit message.
=> This also indicates poor maintainability.
* relies heavily on several spinlocks.
As a result of this shortcomings, the code is slow and does not
even support the most basic 11n requirement: HT station mode.
Therefore, I request to purge my heap of **** from the kernel:
"ar9170: implement transmit aggregation".
The next item on the agenda is: (re-)start from scratch with
an adequate design to accommodate the special requirements
and features of the available frameworks and tools.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes a regression introduced by the following patch:
"ar9170: load firmware asynchronously"
When we kick off a firmware loading request and then unbind,
or disconnect the usb device right away, we get into trouble:
> ------------[ cut here ]------------
> WARNING: at lib/kref.c:44 kref_get+0x1c/0x20()
> Hardware name: 18666GU
> Modules linked in: ar9170usb [...]
> Pid: 6588, comm: firmware/ar9170 Not tainted 2.6.34-rc5-wl #43
> Call Trace:
> [<c102b05e>] ? warn_slowpath_common+0x6e/0xb0
> [<c117c93c>] ? kref_get+0x1c/0x20
> [<c102b0b3>] ? warn_slowpath_null+0x13/0x20
> [<c117c93c>] ? kref_get+0x1c/0x20
> [<c117bb2f>] ? kobject_get+0xf/0x20
> [<c124d630>] ? get_device+0x10/0x20
> [<c124e5a0>] ? device_add+0x60/0x530
> [<c117b8b5>] ? kobject_init+0x25/0xa0
> [<c12569f9>] ? _request_firmware+0x139/0x3e0
> [<c1256cc0>] ? request_firmware_work_func+0x20/0x70
> [<c1256ca0>] ? request_firmware_work_func+0x0/0x70
> [<c103ff24>] ? kthread+0x74/0x80
> [<c103feb0>] ? kthread+0x0/0x80
> [<c1003136>] ? kernel_thread_helper+0x6/0x10
>---[ end trace 2d50bd818f64a1b7 ]---
- followed by a random Oops -
Avoid that by waiting for the firmware loading to finish
(whether successfully or not) before the unbind in
ar9170_usb_disconnect.
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Bug-fixed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If bit 29 is set, MAC H/W can attempt to decrypt the received aggregate
with WEP or TKIP, eventhough the received frame may be a CRC failed
corrupted frame. If this bit is set, H/W obeys key type in keycache.
If it is not set and if the key type in keycache is neither open nor
AES, H/W forces key type to be open. But bit 29 should be set to 1
for AsyncFIFO feature to encrypt/decrypt the aggregate with WEP or TKIP.
Cc: stable@kernel.org
Reported-by: Johan Hovold <johan.hovold@lundinova.se>
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: Ranga Rao Ravuri <ranga.ravuri@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
TX interrupt mitigation reduces the number of interrupts
by addressing several interrupt actions (AR_IMR_TXOK,
AR_IMR_TXDESC) all in one interrupt so when enabling
it discard setting the other interrupts.
Without this TX interrupt mitigation would actually
increase the number of interrupts two-fold. We still
leave TX interrupt mitigation disabled as it is still
being tested.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When the noisefloor calibration times out, do not load -50 into
the registers, since this might cause rx issues. Instead, leave
enough time for the noise floor calibration to complete until
the next check.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since the new AR9003 EEPROM code does tune the card for the configured
tx power level, we need to fill in the correct power limits in the TPC
part of the DMA descriptor.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Combine multiple checks that were supposed to check for the same
conditions, but didn't. Always enable fast PLL clock on AR9280 2.0
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fast clock operation (44Mhz) is enabled for 5Ghz in ar9003, so
take care of the conversion from usec to hw clock.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Disable TX IQ calibration, it was prematurely enabled in
previous versions.
Cc: Paul Shaw <Paul.Shaw@Atheros.com>
Cc: Thomas Hammel <Thomas.Hammel@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This synchs up the initvals to the values used on the
Atheros HAL for AR9003. This specific change adds support
for a new high power module.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
A bunch of validation and processing in the RX IRQ handler
can be moved to the RX tasklet. The IRQ handler is
already heavy, with the memory allocation for handling
stream mode. Also, a memcpy of 40 bytes for every packet
can be avoided in the handler.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Check for the endpoint IDs when processing
TX completions and drop the unsupported EPIDs.
We can add other endpoints (UAPSD,..) when support
is added.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
All commands to the target are disabled when the device
is unplugged, but a normal module unload has to be
differentiated from this case, as we could still receive
data in the RX endpoint. Fix this by checking if the
device is attached or not.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
My patch "ath9k_htc: Handle WMI timeouts properly" introduced
a race condition in WMI command processing. The last issued command
should be stored _before_ issuing a WMI command. Not doing this
would result in the WMI event IRQ dropping correct command responses
as invalid.
Fix this race by storing the command id correctly.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Completion of WMI commands take a longer time
on some platforms. Increase the timeout value
to handle this.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When handling the REGIN callback, processing
the incoming data first should be the preferred
mode of operation. Allocation of a new SKB may fail,
in which case, the URB will not be resubmitted.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
So, apparently there is a USB reboot command
that the target accepts. Using this instead of
usb_reset_device() fixes the issue of "descriptor read error"
that pops up on repeated load/unload.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In the TX callback, the HTC layer has to pass the
priv pointer that was registered during service initialization.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There is no reason to disable the PHY Error / MIB counters
when the module is being unloaded.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes a code segment in configpciepowersave()
to make use of multiple register writes.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When the USB device has been unplugged, there is
no point in trying to send commands to the target.
Fix this by denying all WMI commands in such a case.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch simplifies URB management for transmission,
by removing the 'FLUSH' variable (which is not needed,
since we can determine if the URB has been killed by
looking at the URB status), and also handling the STOP
case properly.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This makes ar5416Addac_9160 and ar5416Addac_9160 const
I guess we skipped them long ago.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Supported only for single stream rates by the hardware
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
AR9300 based hardware can 3x3 MCS rates, this should be set in the
HT capabilities.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Instead of increasing bits_per_symbol for supporting more streams, keep
it single-stream only and multiply the values by the numer of streams.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Include MCS0-31 and also add SGI for HT20. This makes it
possible to support more different rate combinations with
newer hardware.
Based on a patch by Selvam. T.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This adds the first element of survey data, the noise floor figure.
Signed-off-by: Holger Schurig <holgerschurig@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When I set up multiple VAPs with ath9k, I encountered an issue that
the traffic may be lost after a while.
The detailed phenomenon is
1. After a while the clients connected to one of these VAPs will get
into a state that no broadcast/multicast packets can be transfered
successfully while the unicast packets can be transfered normally.
2. Minutes latter the unitcast packets transfer will fail as well,
because the ARP entry is expired and it can't be freshed due to the
broadcast trouble.
It's caused by the group key overwritten and someone discussed this
issue in ath9k-devel maillist before, but haven't work out a fix yet.
I referred the method in madwifi, and made a patch for ath9k.
The method is to set the high bit of the sender(AP)'s address, and
associated that mac and the group key. It requires the hardware
supports multicast frame key search. It seems true for AR9160.
Not sure whether it's the correct way to fix this issue. But it seems
to work in my test. The patch is attached, feel free to revise it.
Signed-off-by: Daniel Yingqiang ma <yma.cool@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes a bunch of endian issues that
were exposed by sparse. It's a miracle that the driver
worked at all till now.
The Lord be praised.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If a WMI command has timed out for some reason,
a late WMI response would end up updating the
response region of a new WMI request that has been
issued in the meantime.
Fix this race condition by dropping a WMI response
if a new WMI command has been issued.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There is no point in trying to set the LED pin
when the module is being unloaded. The target
would be reset anyway.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch adds macros at certain places
which could be optimized for multiple register writes.
The performance of ath9k_htc improves considerably,
especially reducing the latency involved in a scan run.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Programming the opmode in the HW can be done
before the assoc_id and STA_ID registers are
setup. This helps ath9k_htc when multiple register
writes are used.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch adds support for writing multiple registers
in a single USB command.
Specific calls from the HW code that performs multiple
register writes would be modified to make use of this
in subsequent patches.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is required to implement delayed/buffered
register writes in ath9k_htc.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch cleans up beacon configuration,
removing a redundant interface type check
and updating beacon interval in the correct place.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
According to tests, both TSF lower and upper registers kept counting, so
the higher part could have been updated after the lower part has been
read, as shown in the following log where the upper part is read first
and the lower part next.
tsf = {00000003-fffffffd}
tsf = {00000003-00000001}
tsf = {00000004-0000000b}
This patch corrects this by checking that the upper part has not been
changed while the lower part was read. It has been tested in an IBSS
network where artifical IBSS merges have been done in order to trigger
hundreds of rollover for the TSF lower part.
It follows the logic mentionned by Derek, with only 2 register reads
needed at each additional steps instead of 3 (the minimum number of
register reads is still 3).
Signed-off-by: Benoit Papillault <benoit.papillault@free.fr>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The first AR9003 hardware family device supported is the
AR9300, which has the vendor:device id 168c:0030
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
LDPC is enabled by the rate control if the its determined
that the target peer supports LDPC. We would have already
intersected the HT capabilities so if our peer supports
LDPC so do we.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Also add a function to clean up tx status ring.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Enable CRC check on the descriptor fetched from host on AR9003
upon reseting the TX queue.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Also reset tx status ring suring chip reset.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The AR9002 hardware code enables aggregation for WEP but
mac80211 doesn't enable aggregation with WEP, and the AR9003
code family does not need this so skip it for now for AR9003
but leave the code and annotate we should eventually consider
how to remove this in consideration for the HAL unification
goals.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The asynch fifo code is specific to >= AR9287 so stuff it
into the AR9002 hardware family code and skip it for AR9003
cards.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is done depending on what the EEPROM settings indicates.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Luis R. Rodriguez