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: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John 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: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The broadcast bit is in the first, not the last octet..
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We are not correctly listening to the regulatory max bandwidth
settings. To actually make use of it we need to redesign things
a bit. This patch does the work for that. We do this to so we
can obey to regulatory rules accordingly for use of HT40.
We end up dealing with HT40 by having two passes for each channel.
The first check will see if a 20 MHz channel fits into the channel's
center freq on a given frequency range. We check for a 20 MHz
banwidth channel as that is the maximum an individual channel
will use, at least for now. The first pass will go ahead and
check if the regulatory rule for that given center of frequency
allows 40 MHz bandwidths and we use this to determine whether
or not the channel supports HT40 or not. So to support HT40 you'll
need at a regulatory rule that allows you to use 40 MHz channels
but you're channel must also be enabled and support 20 MHz by itself.
The second pass is done after we do the regulatory checks over
an device's supported channel list. On each channel we'll check
if the control channel and the extension both:
o exist
o are enabled
o regulatory allows 40 MHz bandwidth on its frequency range
This work allows allows us to idependently check for HT40- and
HT40+.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch makes the return type of some of the functions
void as those functions always return true
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The AR_SREV_9285_1[12]_OR_LATER macros already contains the
AR_SREV_9285 check.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On x86 this allows us to do the following small savings:
shave off 23 % off of the module's data, and
shave off 6 % off of the module's text.
We save 456 bytes, for those counting.
$ size ath9k.ko
text data bss dec hex filename
250794 3628 1600 256022 3e816 ath9k.ko
$ size ath9k-old.ko
text data bss dec hex filename
239114 15308 1600 256022 3e816 ath9k-old.ko
$ du -b ath9k.ko
4034244 ath9k.ko
$ du -b ath9k-old.ko
4033788 ath9k-old.ko
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix this build error when CONFIG_PM is not set:
drivers/net/wireless/ath/ar9170/usb.c: In function 'ar9170_usb_probe':
drivers/net/wireless/ath/ar9170/usb.c:692:
error: 'struct usb_device' has no member named 'reset_resume'
Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add LED support on the IBM ThinkPad 11a/b/g Wireless LAN Mini Express
Adapter (AR5BXB6), found on the IBM/Lenovo Thinkpad X60/T60/Z60 series.
Signed-off-by: Paride Legovini <legovini@spiro.fisica.unipd.it>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Update ath5k to use the ctl settings for tx power based on current
regulatory domain.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Add spur filter support for RF5413 and later chips
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Add code to support the various antenna scenarios supported by hw
* For now hardcode the default scenario (single or dual omnis with
tx/rx diversity working and tx antenna handled by session -hw keeps
track on which antenna it got ack from each ap/station and maps each
ap/station to one of the antennas-).
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
After some debuging we were hitting the following bugs so far...
* Due to huge channel list hostapd couldn't get infos from the driver
and couldn't set the channel. If we manualy set the channel after
hostapd starts (by setting channel to 0 -auto), beacons are sent
but they wont show up on scan because they are malformed (they have
channel = 0 because hostapd doesn't update the channel info -this is
probably a hostapd bug so i'm CCing Jouni) and they get dropped. Bob
fixed this by only allowing standard channels to be registered so
now hostapd works as expected.
* Docs (and HAL source) say that we must write 0 on timer0 when
operating on AP mode to start TSF increment but this seems to
mess with DBA in many cases and beacon queue never gets started.
We fixed that on the previous patch.
We have some more things to deal with...
* For some reason (hw bug or something else) after restarting hostapd
a few times, beacon inteval seems to change from 100ms to a sec
(we get one beacon per sec).
* We need to set sleep timers on STA mode and enable power saving +
support PCF.
...but i think it's time we enable AP support "officialy" so that
we can get more feedback from users. I ran ath5k with the mentioned
patches + hostapd 0.6.8 and AP mode worked fine (it had some less
throughput on my tests than IBSS but it worked).
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Write next beacon timer even on AP mode since without this we get
no beacons + ath9k does it too. Docs say that we must write 0 on
this register on AP mode to start TSF increment, we do both to be
on the safe side.
* Fix num_tx_pending function, we never read the register :P that's
why we got all those "beacon queue 7 didn't stop messages".
* Put full prioriy on beacon queue, lock all queues with lower
priority using the arblock and also bypass any arblock by seting
the arblock ignore flag.
* For the CAB queue (do we need this thing ?, it seems crap) since
it's supposed to fire up after each beacon (we don't use it on driver
part, ath9k/MadWiFi does), don't make it DBA gated but instead make
it fire after each beacon by using the beacon sent gated flag.
* Increase bmiss threshold to 10, that's what we used on MadWiFi for
a long time. Also when we have pending frames on the beacon queue (we
got a beacon that didn't make it on the air) it's more likely that
the beacon queue never started, probably due to faulty DBA setting,
so change that "beacon queue didn't stop" message.
Tested this with AP mode and IBSS mode and seems to work fine ;-)
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Put remaining EEPROM information on ee struct and remove is_hb63
function.
Now we also have rfkill stuff available.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Read Spur channel information from EEPROM and use default channels
for RF5413 compatible chips that don't have this info on EEPROM.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Now that we have regulatory control enable the driver to set
txpower on hw
* Also use txpower table offset so that we can match
power range set by user/driver with indices on power table.
Tested 2 different cards (a CM9 and an RF5112-based ubnt) and got
the same output using a remote machine to measure per-packet rssi
(conected the cards using attenuators). I also switched between
various tx power levels and i saw an equal power change on the remote
machine (so txpower changes as expected) and verified that we have
the same output on each rate.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The spin_lock handling uses lots of instructions on some archs.
With this patch the size of the ath9k module will be significantly
smaller.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Check for IEEE80211_TX_CTL_NO_ACK instead of is_multicast_ether_addr
when determining whether to use lowest rate without retries.
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Ben Greear points out that the "too many interrupts" message will
never print in the intended case since the interrupt counter
will be -1 after the loop. Change it to pre-decrement so it will
be 0 on the thousandth iteration.
Cc: Ben Greear <greearb@candelatech.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
commit 8e218fb24f reverted the previous
patch (commit 925be8a307).
The C99 specification states in section 6.11.5:
The placement of a storage-class specifier other than at the
beginning of the declaration specifiers in a declaration is an
obsolescent feature.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Acked-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
remove redundant test: outlen is unsigned
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch takes care of an outstanding comment in
"[PATCH] ar9170usb: fix hang on resume" commit message.
>However, the device does not accept the firmware on resume.
>and it will exit with:
>
>> firmware part 1 upload failed (-71).
>> device is in a bad state. please reconnect it!
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Tested-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Set null key type even on ar5211, otherwise it en/decrypts every frame with
protected bit set which renders the card unusable on encrypted networks.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Luis R. Rodriguez <lrodriguez@atheros.com>
Cc: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch uncomment a few lines that survived the RFCs.
However, there is not much to worry about, since AP mode is
not officially advertised and supported.
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Otus uses slightly different set of "Minimum MPDU Start Spacing" values
than the 802.11n D2.0 specifies. (the whole table is shifted by one and
therefore the 16us spacing is not officially available!)
And while we're at it, we also initialize our MAC's density register.
So, this annoying _feature_ will not break TX A-MPDU later.
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The config_interface method is a little strange, it contains the
BSSID and beacon updates, while bss_info_changed contains most
other BSS information for each interface. This patch removes
config_interface and rolls all the information it previously
passed to drivers into bss_info_changed.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We currently have two beacon interval configuration knobs:
hw.conf.beacon_int and vif.bss_info.beacon_int. This is
rather confusing, even though the former is used when we
beacon ourselves and the latter when we are associated to
an AP.
This just deprecates the hw.conf.beacon_int setting in favour
of always using vif.bss_info.beacon_int. Since it touches all
the beaconing IBSS code anyway, we can also add support for
the cfg80211 IBSS beacon interval configuration easily.
NOTE: The hw.conf.beacon_int setting is retained for now due
to drivers still using it -- I couldn't untangle all
drivers, some are updated in this patch.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
net/mac80211/tx.c: In function ‘ieee80211_tx_h_select_key’:
net/mac80211/tx.c:448: warning: ‘key’ may be used uninitialized in this function
drivers/net/wireless/ath/ath9k/rc.c: In function ‘ath_rc_rate_getidx’:
drivers/net/wireless/ath/ath9k/rc.c:815: warning: ‘nextindex’ may be used uninitialized in this function
drivers/net/wireless/hostap/hostap_plx.c: In function ‘prism2_plx_probe’:
drivers/net/wireless/hostap/hostap_plx.c:438: warning: ‘cor_index’ may be used uninitialized in this function
drivers/net/wireless/hostap/hostap_plx.c:438: warning: ‘cor_offset’ may be used uninitialized in this function
Signed-off-by: John W. Linville <linville@tuxdriver.com>
With this patch ar9170 is capable of receiving aggregated 802.11n frames
and sniffing on most networks without having a "debug message overhead".
(Includes phy initialization requested by
Johannes Berg <johannes@sipsolutions.net> -- JWL)
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch adds support for configuring HT40 channels
and receiving HT40 to ar9170. Receiving aggregation
doesn't seem to work right now, so it's not enabled.
Same goes for TX aggregation, but that probably needs
even more work.
With this, I can receive roughly 33 Mbits/sec.
The HT capabilities are a little odd, I tried following
otus here -- in particular having SGI_40 but not SGI_20
is a little weird but afaict that's what otus does.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Trying to separate header files into net/wireless.h and
net/cfg80211.h has been a source of confusion. Remove
net/wireless.h (because there also is the linux/wireless.h)
and subsume everything into net/cfg80211.h -- except the
definitions for regulatory structures which get moved to
a new header net/regulatory.h.
The "new" net/cfg80211.h is now divided into sections.
There are no real changes in this patch but code shuffling
and some very minor documentation fixes.
I have also, to make things reflect reality, put in a
copyright line for Luis to net/regulatory.h since that
is probably exclusively written by him but was formerly
in a file that only had my copyright line.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When the EEPROM is not in good condition we cannot continue so
we currently bail out but only ath5k is bailing out properly.
Both ath9k and ar9170 were proceeding and if a user were to run
into this they'd see an obscure panic. Lets propagate the error
as intended and make sure we inform the user by lifting the
error message from debug to a kernel error.
Stable note: You can find a port of this page here:
http://bombadil.infradead.org/~mcgrof/patches/ath9k/ath9k-fix-eeprom.patch.txt
Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Grabbing an ath5k_buf then dropping the lock is racy because the
referenced descriptor can be obtained in another thread and released
before the buffer is handed to the hardware. Likewise, manipulating
sc->rxlink without the lock can lead to having multiple self-linked
hardware descriptors.
Changes-licensed-under: 3-Clause-BSD
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch simplifies the code used to detect when the
self-linked DMA buffer is still in use by hardware, by
checking the hardware's rxdp register instead of looking
at the software buffer list.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Current code uses int types, but both modparams are boolean values.
Changes-licensed-under: 3-Clause-BSD
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
For embedded platforms, beacon transmission can be starved when
flooded with data packets. Prioritize beacons by giving the beacon
queue the first shot when the isr completes.
Changes-licensed-under: 3-Clause-BSD
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch corrects a few errors in the initvals tables to match those
in the HAL tables. Namely, remove a couple of repetitions, fix some
turbo mode errors, and correct a register for the CCK rate power table.
Changes-licensed-under: ISC
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch adds licensing, author information and a description to the module.
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It is already handled properly in ath9k_hw_getnf.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes a bug in ath9k_hw_init_cal() where the wrong
calibration was being done for non-AR9285 chipsets.
Also add a few helpful comments.
Cc: stable@kernel.org
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch replaces old 'hal_' prefixes with 'ath9k_'.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch cleans up the functions dealing with calibration,
using proper return values.
ath9k_hw_per_calibration(), ath9k_hw_calibrate now return bool values
instead of setting error values in the function arguments.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The various ANI timers have to be initialized properly when
starting the calibration timer.
Cc: stable@kernel.org
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ADC gain calibration has to be done for all non 2GHZ-HT20 channels.
Regression from "ath9k: use ieee80211_conf on ath9k_hw_iscal_supported()"
Cc: stable@kernel.org
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The operating HT mode is stored in chanmode and
not channelFlags.
Cc: stable@kernel.org
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>