Break out the ath PCI logic into a separate device/module.

Introduce the AHB glue for Atheros embedded systems. Right now it's
hard-coded for the AR9130 chip whose support isn't yet in this HAL;
it'

Break out the ath PCI logic into a separate device/module.

Introduce the AHB glue for Atheros embedded systems. Right now it's
hard-coded for the AR9130 chip whose support isn't yet in this HAL;
it'll be added in a subsequent commit.

Kernel configuration files now need both 'ath' and 'ath_pci' devices; both
modules need to be loaded for the ath device to work.

show more ...

According to ath9k recv.c, one shouldn't be doing self-linked descriptors
in the RX path when doing 11n and block-ack'ed frames. Apparently, the MAC
will loop over that self-linked descriptor and tre

According to ath9k recv.c, one shouldn't be doing self-linked descriptors
in the RX path when doing 11n and block-ack'ed frames. Apparently, the MAC
will loop over that self-linked descriptor and treat it as "good enough"
for (incorrectly!) ACKing the frames in the block-ack.

Until I figure out how to work around this issue in the future, this counter
will tell me if packet RX processing ever gets to the point where it's
touching the self-linked descriptor. If there's ever enough packets to get
to that point, BA's will be invalid and likely very unhappy.

show more ...

Fix typo.

Rename AH_ENABLE_11N to ATH_ENABLE_11 - the HAL supports 11n by
default but the ath driver doesn't. This is a much more consistent
name.

Add in the hardware PS-POLL frame reception setting, but leave it disabled
by default.

Adventourous souls with an AR9220/AR9280 or later and who have a device
that sends PS-POLL frames may wish to t

Add in the hardware PS-POLL frame reception setting, but leave it disabled
by default.

Adventourous souls with an AR9220/AR9280 or later and who have a device
that sends PS-POLL frames may wish to try tinkering with this option and
get back to me.

show more ...

Enable setting the MCS rate bit for ast_tx_rate.

This allows ath_stats to print the MCS rate when TX'ing.

Flip this over to be a configurable option for people who wish to play with it.

It's still not ready for prime-time - there's some TX niggles with these 11n
cards that I'm still trying to wrap my he

Flip this over to be a configurable option for people who wish to play with it.

It's still not ready for prime-time - there's some TX niggles with these 11n
cards that I'm still trying to wrap my head around, and AMPDU-TX is just not
implemented so things will come to a crashing halt if you're not careful.

show more ...

This isn't actually needed any longer, A-MPDU frames work fine if only tagged for 11n nodes.

Merge svn+ssh://svn.freebsd.org/base/head@219553

Break the keycache management functions out into if_ath_keycache.c .

Migrate the sysctl related routines (statistics, debugging, etc) out of
if_ath.c and into if_ath_sysctl.c .

Fix formatting of new stat sysctls; add descriptions

Add a new counter which tracks frames TX'ed with HT protection.

Merge svn+ssh://svn.freebsd.org/base/head@218816

Disable short-GI in 20mhz mode - the hardware doesn't support this.

Some statistics additions - prepare for error codes > 32 (since the AR5416
error mask is > 5 bits) and add some extra CRC/HT40/ShortGI counters to
help debug 802.11n issues.

Add in the (very!) optional glue to flip the 11n bits for if_ath.

There's still a lot of random issues to sort out with the radio side of
things and AMPDU RX handling (and completely missing AMPDU T

Add in the (very!) optional glue to flip the 11n bits for if_ath.

There's still a lot of random issues to sort out with the radio side of
things and AMPDU RX handling (and completely missing AMPDU TX handling!)
but if people wish to give this a go and assist in debugging the
issues, they can define ATH_DO_11N to enable it.

I'm just re-iterating - this is here to allow people to assist in
further 11n development; it is not any indication that the 11n support
is complete and functional.

Important notes:

* This doesn't support 1-stream cards yet - (eg AR9285) - the various bits
that negotiate TX/RX MCS don't know not to try >1 stream TX or negotiate
1-stream RX; so don't enable 11n unless you've first taught the rate
control module and the net80211 stack to negotiate 1-stream stuff;

* The only rate control module minimally 11n aware is ath_rate_sample;

* ath_rate_sample doesn't know about HT/40; so airtime will be incorrectly
calculated;

* The AR9160 and AR9280 radio code is unreliable at the higher MCS rates for
some reason; this will definitely impact 11n performance;

* AMPDU-TX isn't yet implemented;

* AMPDU-RX may be a bit buggy still and will definitely suffer from the
radio unreliability mentioned above (ie, don't expect 150/300mbit
RX just yet.)

show more ...

Fix the keycache behaviour for multicast keycache search.

The correct bit to set is 0x1 in the high MAC address byte, not 0x80.
The hardware isn't programmed with that bit (which is the multicast
ad

Fix the keycache behaviour for multicast keycache search.

The correct bit to set is 0x1 in the high MAC address byte, not 0x80.
The hardware isn't programmed with that bit (which is the multicast
adress bit.)

The linux ath9k keycache code uses that bit in the MAC as a "this is
a multicast key!" and doesn't set the AR_KEYTABLE_VALID bit.
This tells the hardware the MAC isn't to be used for unicast destination
matching but it can be used for multicast bssid traffic.

This fixes some encryption problems in station mode.

PR: kern/154598

show more ...

net80211 really doesn't want A_MPDU to appear on non-11n station node mbufs.
Revert back to the previous method of doing it for where a node can be
identified and it's an 11n node.

I'll have to do s

net80211 really doesn't want A_MPDU to appear on non-11n station node mbufs.
Revert back to the previous method of doing it for where a node can be
identified and it's an 11n node.

I'll have to do some further research into exactly what is being messed up
with the sequence number matching and I'll then revisit this.

show more ...

Add in a per phy error sysctl.

Just tag all RX packets as needing reorder processing for now.

This fixes two problems -

* All packets need to be processed here, not just aggregate ones - as any
received frames (AMPDU or otherw

Just tag all RX packets as needing reorder processing for now.

This fixes two problems -

* All packets need to be processed here, not just aggregate ones - as any
received frames (AMPDU or otherwise) in the given TID (traffic class id)
will update the sequence number and, implied with that, update the window;
* It seems there's situations where packets aren't matching a current node but
somehow need to be tracked. Thus just tag them all for now; I'll figure out
the why later.

Whilst I'm here, bump the stats counters whilst I'm at it.

This fixes AMPDU RX in my tests; the main problems now stem from what look
like PHY level error/retransmits which are impeding general throughput, incl.
AMPDU.

show more ...

Only tag packets with the A-MPDU bit if they were part of an A-MPDU RX.

Whilst I'm here, add a counter to count said packets.

Oops, fix newbie mistake that breaks the normal build.

Disable the code I previously added from Rui's 802.11n branch.

A-MPDU RX interferes with packet retransmission/reordering.
In local testing, I was seeing A-MPDU being negotiated and then
not used by

Disable the code I previously added from Rui's 802.11n branch.

A-MPDU RX interferes with packet retransmission/reordering.
In local testing, I was seeing A-MPDU being negotiated and then
not used by the AP sending frames to the STA; the STA would then
treat non A-MPDU frames that are retransmits as out of the window
and get plain confused.

The hardware RX status descriptor has a "I'm part of an aggregate"
bit; so this should eventually be tested and then punted to the
A-MPDU reorder handling only if it has this bit set.

show more ...

Remove the now unneeded XXX.