Since we have a TODO item to make all station
management dependent on virtual interfaces, I
figured I'd start with pushing such a change
to drivers before more drivers start using the
ieee80211_find_sta() API with a hw pointer and
cause us grief later on.

For now continue exporting the old API in form
of ieee80211_find_sta_by_hw(), but discourage
its use strongly.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
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>

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

ath9k uses this for now, ath9k_htc is expected to re-use this
as well. We lave ath5k as is, but it certainly can also be
converted later.

The ath9k module parameter and debugfs entry is kept.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Also make ath5k and ath9k use it, and share register definitions.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This ensures that we can access common on hw related code
independent of the driver core.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

These are common amongst ath9k and ath5k, so put them into the
common structure and make ath9k to use it. ar9170 can use macaddr,
and curbssid. We'll change ath5k and ar9170 separately.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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

DPRINTF() is used in hw specific related code, as such
ensure we don't rely on the private driver core ath_softc
struct when calling it. Drivers can then implement their
own DPRINTF() as they see fit.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

BAR frames have to be sent to mac80211 only if the
current channel is HT. Also, move the macro to
enum ath9k_rx_filter.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Support for FIF_OTHER_BSS was missing.  This patch adds support for this
filtering mode which in turn resolves a problem where mesh interfaces would not
receive broadcast traffic.
Signed-off-by: NJavier Cardona <javier@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Other than ns_avgbrssi (Average beacon rssi) no data of
ath9k_node_stats is being used anywhere. Nuke this structure
and move its only useful member to ar5416Anistate. Also cleanup
this redundant data in ath_softc.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Turns out ath5k and ath9k can share the same helper to
allocates RX skbs. We allocate skbs aligned to the cache line
size. This requirement seems to have come from AR5210; when
this was not done it seems sometimes we'd get bogus data. I'm
also told it may have been a performance enhancement
consideration. In the end I can't be sure we can remove this
on new hardware so just keep this and start sharing it through
ath.ko.

Make ath9k start using this, ath5k is next.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ANI uses the beacon RSSI for its operation.
Update this properly.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We used to set pspoll filter on ath9k on AP mode but
we no longer need this mode specific check as mac80211
now does the check for us and informs us when we should
enable pspoll through FIF_PSPOLL.

Cc: Igor Perminov <igor.perminov@inbox.ru>
Cc: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

RSSI reported by the RX descriptor requires little manipulation.
Manipulate and report the correct RSSI to the stack. This will
fix the improper signal levels reported by iwconfig iw dev wlanX
station dump. Also the Link Quality reported seems to be varying
(falls to zero also sometimes) when iperf is run from STA to AP.

Also use the default noise floor for now as the one reported
during the caliberation seems to be wrong.

The Signal and Link Quality before this patch (taken while TX is
in progress from STA to AP)

09:59:13.285428037 Link Quality=29/70  Signal level=-81 dBm
09:59:13.410660084 Link Quality=20/70  Signal level=-90 dBm
09:59:13.586864392 Link Quality=21/70  Signal level=-89 dBm
09:59:13.710296281 Link Quality=21/70  Signal level=-89 dBm
09:59:13.821683064 Link Quality=25/70  Signal level=-85 dBm
09:59:13.933402989 Link Quality=24/70  Signal level=-86 dBm
09:59:14.045839276 Link Quality=26/70  Signal level=-84 dBm
09:59:14.193926673 Link Quality=23/70  Signal level=-87 dBm
09:59:14.306230262 Link Quality=31/70  Signal level=-79 dBm
09:59:14.419459667 Link Quality=26/70  Signal level=-84 dBm
09:59:14.530711167 Link Quality=37/70  Signal level=-73 dBm
09:59:14.642593962 Link Quality=29/70  Signal level=-81 dBm
09:59:14.754361169 Link Quality=21/70  Signal level=-89 dBm
09:59:14.866217355 Link Quality=21/70  Signal level=-89 dBm
09:59:14.976963623 Link Quality=28/70  Signal level=-82 dBm
09:59:15.089149809 Link Quality=26/70  Signal level=-84 dBm
09:59:15.205039887 Link Quality=27/70  Signal level=-83 dBm
09:59:15.316368003 Link Quality=23/70  Signal level=-87 dBm
09:59:15.427684036 Link Quality=36/70  Signal level=-74 dBm
09:59:15.539756380 Link Quality=21/70  Signal level=-89 dBm
09:59:15.650549093 Link Quality=22/70  Signal level=-88 dBm
09:59:15.761171672 Link Quality=32/70  Signal level=-78 dBm
09:59:15.872793750 Link Quality=23/70  Signal level=-87 dBm
09:59:15.984421694 Link Quality=22/70  Signal level=-88 dBm
09:59:16.097315093 Link Quality=21/70  Signal level=-89 dBm

The link quality and signal level after this patch (take while
TX is in progress from STA to AP)

17:21:25.627848091 Link Quality=65/70  Signal level=-45 dBm
17:21:25.762805607 Link Quality=65/70  Signal level=-45 dBm
17:21:25.875521888 Link Quality=66/70  Signal level=-44 dBm
17:21:25.987468448 Link Quality=66/70  Signal level=-44 dBm
17:21:26.100628151 Link Quality=66/70  Signal level=-44 dBm
17:21:26.213129671 Link Quality=66/70  Signal level=-44 dBm
17:21:26.324923070 Link Quality=65/70  Signal level=-45 dBm
17:21:26.436831357 Link Quality=65/70  Signal level=-45 dBm
17:21:26.610356973 Link Quality=65/70  Signal level=-45 dBm
17:21:26.723340047 Link Quality=65/70  Signal level=-45 dBm
17:21:26.835715293 Link Quality=64/70  Signal level=-46 dBm
17:21:26.949542748 Link Quality=64/70  Signal level=-46 dBm
17:21:27.062261613 Link Quality=65/70  Signal level=-45 dBm
17:21:27.174511563 Link Quality=64/70  Signal level=-46 dBm
17:21:27.287616232 Link Quality=64/70  Signal level=-46 dBm
17:21:27.400598119 Link Quality=64/70  Signal level=-46 dBm
17:21:27.511381404 Link Quality=64/70  Signal level=-46 dBm
17:21:27.624530421 Link Quality=65/70  Signal level=-45 dBm
17:21:27.737807109 Link Quality=64/70  Signal level=-46 dBm
17:21:27.850861352 Link Quality=65/70  Signal level=-45 dBm
17:21:27.963369436 Link Quality=64/70  Signal level=-46 dBm
17:21:28.076582289 Link Quality=64/70  Signal level=-46 dBm
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We were not differentiating quality between legacy and HT
configurations. We change this to consider the differences.

New theory for reporting quality:

At a hardware RSSI of 45 you will be able to use MCS 7  reliably.
At a hardware RSSI of 45 you will be able to use MCS 15 reliably.
At a hardware RSSI of 35 you should be able use 54 Mbps reliably.

MCS 7  is the highets MCS index usable by a 1-stream device.
MCS 15 is the highest MCS index usable by a 2-stream device.

All ath9k devices are either 1-stream or 2-stream.

How many bars you see is derived from the qual reporting.

A more elaborate scheme can be used here but it requires tables
of SNR/throughput for each possible mode used. For the MCS table
you can refer to the wireless wiki:

http://wireless.kernel.org/en/developers/Documentation/ieee80211/802.11n

This should fix this bug report:

http://bugzilla.kernel.org/show_bug.cgi?id=13537

Cc: Janath.Peiris@atheros.com
Cc: Matt.Smith@atheros.com
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This helper only clears the SC_OP_WAIT_FOR_{BEACON,CAB} flags.
Remove it and clear these flags directly in the approptiate
places instead.

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

All SC_OP_WAIT_* flags will be cleared in 'ath9k_conf' when PS mode
is disabled, so we don't have to clear it here.

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

Within mac80211, we often need to copy the rx status into
skb->cb. This is wasteful, as drivers could be building it
in there to start with. This patch changes the API so that
drivers are expected to pass the RX status in skb->cb, now
accessible as IEEE80211_SKB_RXCB(skb). It also updates all
drivers to pass the rx status in there, but only by making
them memcpy() it into place before the call to the receive
function (ieee80211_rx(_irqsafe)). Each driver can now be
optimised on its own schedule.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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

If we are in PS mode, we have to process the received frame if
the SC_OP_WAIT_FOR_CAB bit is set.

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

Some APs seem to drift away from the expected TBTT (timestamp %
beacon_int_in_usec differs quite a bit from zero) which can result in
us waking up way too early to receive a Beacon frame. In order to work
around this, re-configure the Beacon timers after having received a
Beacon frame from the AP (i.e., when we know the offset between the
expected TBTT and the actual time the AP is sending out the Beacon
frame).
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When using timeout=0 (PS-Poll) with mac80211, the driver will need to
wake up for TX requests and remain awake until the TX has been
completed (ACK received or timeout) or until the buffer frame(s) have
been received (in case the TX is for a PS-Poll frame).
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We do not need to do this in ath_isr() and it looks like the modified
version ends up being more stable as far as being able receive beacon
frames is concerned. Furthermore, this reduces need to move between
AWAKE and NETWORK SLEEP states when processing some unrelated
interrupts.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The previous implementation was moving back to NETWORK SLEEP state
immediately after receiving a Beacon frame. This means that we are
unlikely to receive all the buffered broadcast/multicast frames that
would be sent after DTIM Beacon frames. Fix this by parsing the Beacon
frame and remaining awake, if needed, to receive the buffered
broadcast/multicast frames. The last buffered frame will trigger the
move back into NETWORK SLEEP state.

If the last broadcast/multicast frame is not received properly (or if
the AP fails to send it), the next Beacon frame will work as a backup
trigger for returning into NETWORK SLEEP.

A new debug type, PS (debug=0x800 module parameter), is added to make
it easier to debug potential power save issues in the
future. Currently, this is only used for the Beacon frame and buffered
broadcast/multicast receiving.
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This makes use of the local fc variable in bit more places and uses a
common helper macro. The part of RX process that delivers skb's to
mac80211 is moved to a separate function in preparation for future
changes that will need to do this from two places. The modifications
here should not result in any functional changes.
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The broadcast bit is in the first, not the last octet..
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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

These are unnecessary constructs in a function.
This patch removes these from both RX and TX init
routines.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Clean debug messages to use appropriate levels,
remove useless messages, and trim the number of
debug levels.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We were claiming DMA buffers on the RX tasklet but never
upon a simple module removal.

Cc: stable@kernel.org
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

How time flies.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We must not disable ACK sending in this case since it would break
normal station operations. In addition, clarify the comment about AP
mode to make more sense.
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We can sleep for memory during init time and so allocating rx buffers,
descriptro buffers with GFP_KERNEL should help us to get rid of transient
alloc fails.
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Allow RX filter to pass through all broadcast/multicast frames (i.e.,
no BSSID filtering) if virtual interfaces are used. Software filtering
will be used in this case to drop broadcast/multicast frames for
foreign BSSIDs.
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The new struct ath_softc::sec_wiphy array is used to store information
about virtual wiphys and select which wiphy is used in calls to
mac80211. Each virtual wiphy will be assigned a different MAC address
based on the virtual wiphy index.
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is the initial step in allowing ath9k to register multiple
virtual radios (wiphys). The goal of virtual radios is to allow the
same radio to be shared for multiple virtual interfaces that may
operate on different channels. The mac80211 virtual interface support
is designed only for single channel operation and as such, it is not
suitable for this type of use. Anyway, it can be used on top of the
virtual radio concept, if desired (e.g., use two virtual radios to
handle two channels and then add multiple mac80211 virtual interfaces
on top of each virtual radio).

The new struct ath_wiphy is now registered as the driver data
structure for wiphy. This structure has a pointer to the shared (among
virtual wiphys of the same physical radio) struct ath_softc data. The
primary wiphy maintains the allocated memory for ath_softc. Secondary
(virtual) wiphys will only allocate the new ath_wiphy structure.

Registration of secondary wiphys is added in a separate patch.
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>