When this PLL hang issue is seen, both Rx and Tx fail to work.
The sqsum_dvc needs to be below 2000 for a good chip. During
this issue the sqsum_dvc value is beyond 80000 and only a
full reset can solve this problem.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add a function to observe the delta VC of BB_PLL.
For a good chip, the sqsum_dvc is below 2000.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The HW has separate filter masks for compressed/uncompressed
BlockAcks and BlockAckRequests. Add them.
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
With this change, less CPU time is spent trying to look for consecutive
pages for rx skbs. This also reduces the socket memory required for IP/UDP
reassembly.
Only two buffers per frame are supported. Frames spanning more buffers
will be dropped, but the buffer size is enough to handle the required
AMSDU size.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commit "ath9k_hw: move AR9280 PCI EEPROM fix to eeprom_def.c"
changed the behavior of INI overriding which is needed only
for PCI cards. Revert to the original check.
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commit "ath9k_hw: Relocate Opmode initialization"
moved the opmode initialization before the STA_ID1 register
was programmed with defaults. This changed the original
behaviour because the re-programming code doesn't take into
account the existing value in the register. Both ath9k and ath9k_htc
were not affected by this change because the opmode is
re-initialized after every reset, when RX is started.
Revert to the original behavior, except keep it outside the
REGWRITE block. This would help remove extraneous opmode calls
in the driver core.
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Now that rx and tx dumps go through the tracing infrastructure,
we no longer need to keep these routines around.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Bruno Randolf <br1@einfach.org>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This adds a few tracepoints to ath5k driver transmit and
receive callbacks in order to record packet traffic.
We record the entire packet in the trace buffer so that
the data can be extracted with trace-cmd and external
plugins.
Compared to the previous debugging calls, this approach
removes an out-of-line function call from the tx and rx
paths in the compiled-in-but-disabled case, while
improving the ability to process the logged data.
A new option, CONFIG_ATH5K_TRACER, is added so that one
may disable the tracepoints completely.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Bruno Randolf <br1@einfach.org>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
IEEE80211_WEP_NKID is not used in ath9k any more since the key handling code
has been moved to ath/.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This enables 4.9GHz frequencies in ath5k if they are allowed as indicated by
the regulatory domain code. Currently this is MKK9_MKKC (0xfe).
Signed-off-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This adds a helper function to ath/regd.c which can be asked if 4.9GHz channels
are allowed for a given regulatory domain code. This keeps the knowledge of
regdomains and defines like MKK9_MKKC in one place. I'm passing the regdomain
code instead of the ath_regulatory structure because this needs to be called
quite early in the driver inititalization where ath_regulatory is not available
yet in ath5k.
I'm using MKK9_MKKC only because this is the regdomain in the 802.11j enabled
sample cards we got from our vendor. I found some hints in HAL code that this
is used by Atheros to indicate 4.9GHz channels support and that there might be
other domain codes as well, but as I don't have any documentation I'm just
putting in what I need right now. It can be extended later.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Shorten some lines and make code more readable.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Various places printing tx queue information used various different ways to
get a tx queue index for printing statistics. Most of these ways were wrong.
ATH_TXQ_AC_* cannot be used as an index for sc->tx.txq, because it is only
used internally for queue assignment.
One place used WME_AC_* as a queue index for sc->debug.stats.txstats, however
this array uses the ath9k_hw queue number as well.
Fix all of this by always using the ath9k_hw queue number as an index, and
always looking it up by going through sc->tx.txq_map.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It does not make much sense to keep the current virtual wiphy implementation
any longer - it adds significant complexity, has very few users and is still
very experimental. At some point in time, it will be replaced by a proper
implementation in mac80211.
By making the code easier to read and maintain, removing virtual wiphy support
helps with fixing the remaining driver issues and adding further improvements.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Instead of spreading ath_wake_mac80211_queue() calls over multiple places
in the tx path that process the tx queue for completion, call it only
where the pending frames counter gets decremented, eliminating some
redundant checks.
To prevent queue draining from waking the queues prematurely (e.g. during
a hardware reset), reset the queue stop state when draining all queues,
as the caller in main.c will run ieee80211_wake_queues(hw) anyway.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The commit 'ath9k: Add more information to debugfs xmit file.' added more
debug counters to ath9k and also added some lines of code to ath9k_hw.
Since ath9k_hw is also used by ath9k_htc, its code must not depend on ath9k
data structures. In this case it was not fatal, but it's still wrong, so
the code needs to be moved back to ath9k.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
"mac80211 will properly assign sequence numbers to QoS-data
frames but cannot do so correctly for non-QoS-data and
management frames because beacons need them from that counter
as well and mac80211 cannot guarantee proper sequencing."
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch syncs up the header files with
the project's main firmware carl9170fw.git.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Remove unused macros and cleanup buffer_type enumeration
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Remove useless test_bit - it's not going to happen because of the way this
function is called only when that bit is set.
And fix some whitespace.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Acked-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We need to read and backup AR_WA register value permanently and reading
this after the chip is awakened results in this register being zeroed out.
This seems to fix the ASPM with L1 enabled issue that we have observed.
The laptop becomes very slow and hangs mostly with ASPM L1 enabled without
this fix.
Cc: Stable Kernel <stable@kernel.org>
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There are few places where we are checking for macversion and revsions
before RTC is powered ON. However we are reading the macversion and
revisions only after RTC is powered ON and so both macversion and
revisions are actully zero and this leads to incorrect srev checks
Incorrect srev checks can cause registers to be configured wrongly and can
cause unexpected behavior. Fixing this seems to address the ASPM issue that
we have observed. The laptop becomes very slow and hangs mostly with ASPM L1
enabled without this fix.
fix this by reading the macversion and revisisons even before we start
using them. There is no reason why should we delay reading this info
until RTC is powered on as this is just a register information.
Cc: Stable Kernel <stable@kernel.org>
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Simplify confusing code and get rid of an unnecessary variable.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When beacons are being added or removed for an interface, ieee80211_beacon_get
will sometimes not return a beacon. This is normal and should not result in
useless logspam.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Remove sc->curband because the band is already stored in the current channel.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Acked-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
sc->curmode is set but never used. Remove it and the helper function. Also the
ath5k_rate_update which is refered to in the comment does not exist (any more?)
so we don't need to setup the band in that place.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Acked-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
They are unused in ath5k and a more detailled definition is in
ath/regd_common.h.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Acked-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add the 802.11j (20MHz channel width) channels to the allowed channels. This
still does not enable 802.11j in ath5k since these frequencies are out of the
configured range. A later patch will deal with that.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Acked-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Rename ath5k_copy_channels() to ath5k_setup_channels() - nothing is copied
here.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Acked-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use mac80211 channel mapping function instead of own homegrown version.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Acked-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Try all xmit queues until the hardware buffers are full.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Acked-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add a misc file to show hardware op-mode, irq setup,
number of various types of VIFs and more.
Also, previous patches were using the wrong xmit queue
indexes. Change to use the internal ath9k indexes instead
of the mac80211 queue indexes.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The system can get into a state where the xmit queue
is stopped, but there are no packets pending, so
the queue will not be restarted.
Add logic to the xmit watchdog to attempt to restart
the xmit logic if this situation is detected.
Example 'dmesg' output:
ath: txq: f4e723e0 axq_qnum: 2, mac80211_qnum: 2 axq_link: f4e996c8 pending frames: 1 axq_acq empty: 1 stopped: 0 axq_depth: 0 Attempting to restart tx logic.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
To try to figure out why xmit logic hangs.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The stations hold the ath_node, which holds the tid
and other xmit logic structures. In order to debug
stuck xmit logic, we need a way to print out the tid
state for the stations.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Show counters for pkts sent directly to hardware and
those queued in software.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If the txq->axq_q is empty, the code was breaking out
of the tx_processq logic without checking to see if it should
transmit other queued AMPDU frames (txq->axq_acq).
This patches ensures ath_txq_schedule is called.
This needs review.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Should help debug strange tx lockup type issues.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
I thought this might help track down stuck queues, etc.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The aggregation code currently doesn't implement the
buffer size negotiation. It will always request a max
buffer size (which is fine, if a little pointless, as
the mac80211 code doesn't know and might just use 0
instead), but if the peer requests a smaller size it
isn't possible to honour this request.
In order to fix this, look at the buffer size in the
addBA response frame, keep track of it and pass it to
the driver in the ampdu_action callback when called
with the IEEE80211_AMPDU_TX_OPERATIONAL action. That
way the driver can limit the number of subframes in
aggregates appropriately.
Note that this doesn't fix any drivers apart from the
addition of the new argument -- they all need to be
updated separately to use this variable!
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When using a mixture of AP and Station interfaces,
the hardware mode was using the type of the
last VIF registered. Instead, we should keep track
of the number of different types of vifs and set the
mode accordingly.
In addtion, use the vif type instead of hardware opmode
when dealing with beacons.
Attempt to move some of the common setup code into smaller
methods so we can re-use it when changing vif mode as
well as adding/deleting vifs.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Because the sendbar variable was not reset to zero, the stack would send
Block ACK requests for all subframes following the one that failed, which
could mess up the receiver side block ack window.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Sometimes the first TID in the first AC's list is not available for forming
a new aggregate (the BAW might not allow it), however other TIDs may have
data available for sending.
Prevent a slowdown of other TIDs by going through multiple entries until
we've either hit the last one or enough AMPDUs are pending in the hardware
queue.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Vivek Natarajan