In ad-hoc mode, beacon timers are configured differently compared to AP
mode, and (depending on the scenario) can vary enough to make the beacon
tasklet not detect slot 0 based on the TSF.
Since staggered beacons are not (and cannot be) used in ad-hoc mode, it
makes more sense to just hardcode slot 0 here, avoiding unnecessary
TSF reads and calculations.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Reported-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In order to provide multiple interfaces for a single device,
the driver will be required to advertise all possible
interface configurations to the stack.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
we are not doing anything by tracking the number of pending frames.
bail out when we first find a pending frame in any one of the 10 queues.
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
some times the rssi control descriptor for the main antenna may be
negative like that of alternate antenna, hence before incrementing
packet counts/rssi of main/alternate antenna make sure both main_rssi
and alt_rssi are positive only. this avoids wrong selection of antenna
due to diversity
Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
configure fast diversity bias based on the antenna diversity group and
based on main/alt LNA configurations. also configure main antenna and
alternate antenna to gain-table 0 for diversity group 2(AR9485)
Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
for the diversity group 2(AR9485) we swap the LNA's of main/ALT antenna
based on alternate antenna's rssi average in comparision with main
antenna's rssi, while for AR9285(antenna diversity group 0)we still
follow the older method of looking at the packet count in alternate
antenna
Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
AR9285 belongs to diversity group 0 and AR9485 belongs to diversity
group 2. Based on the diversity group we configure certain antenna
diversity paramaters such as lna1_lna2_delta and fast diversity
bias values. For AR9485 we have some gain table parameter which
selects the gain table 0/1 for main and alternate antenna
Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
these are the two important modules that will be called by the antenna
diversity algorithm module in the rx. this will continuosly configure
the hardware based on the current diversity status obtained
from the algorithm
Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* enable LNA-diversity, fast-diversity for AR9485 based on
the value read from EEPROM content
* if antenna diversity/combining is supported, set LNA1 for the main
antenna and LNA2 for the alternate antenna based on the new diversity
algorithm
Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Cc: Luis Rodriguez <Luis.Rodriguez@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
define few registers and macros to configure/enable Antenna diversity
parameters in AR9485
Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
read antenna diversity and combining information from the EEPROM.
Enable antenna diversity/combining feature only when both LNA
diversity and fast diversity are supported
Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Tested-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
this is necessary to support Antenna diversity and combining in new chip
sets such as AR9485, previously Antenna diversity support is available
only in AR9285
Cc: Gabriel Tseng <Gabriel.Tseng@Atheros.com>
Cc: Senthilkumar Balasubramanian <Senthilkumar.Balasubramanian@Atheros.com>
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
XB113 (AR9380) 3x3 SB 5G only cards were failing to connect to APs
due to incorrect xpabiaslevel configuration. fix it.
Cc: stable@kernel.org
Cc: Ray Li <ray.li@greenwavereality.com>
Cc: Kathy Giori <kathy.giori@atheros.com>
Cc: Aeolus Yang <aeolus.yang@atheros.com>
Cc: compat@orbit-lab.org
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The XB113 cards are single band, 5 GHz-only, but the
default settings were configured to assume it was dual
band. Users of these cards then would see 2.4 GHz channels
but you would never get any scan results from these channels
given that the radio is not present.
Cc: stable@kernel.org
Cc: Fiona Cain <Fiona.Cain@atheros.com>
Cc: Ray Li <ray.li@greenwavereality.com>
Cc: Kathy Giori <kathy.giori@atheros.com>
Cc: Aeolus Yang <aeolus.yang@atheros.com>
Cc: Dan Friedman <dan.friedman@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Only leave filtering enabled for AP or VLAN interfaces, clear the
destination mask for all other interfaces.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Reported-by: Ben Greear <greearb@candelatech.com>
Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This was introduced in 2.6.39-rc1 it seems.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Tested-by: Sedat Dilek <sedat.dilek@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Mesh beaconing on ath9k was broken by this commit:
commit 4801416c76
Author: Ben Greear <greearb@candelatech.com>
Date: Sat Jan 15 19:13:48 2011 +0000
This patch assigns the right opmode when the device is used in mesh
mode.
Reported-by: Fabrice Deyber fabricedeyber@agilemesh.com
Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This beacon rssi will be used to set noisefloor during ani reset.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The average beacon rssi which will be used by ani is not updated
in adhoc mode.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
By changing DCU backoff threshold for AR9340 to 1, helps to
reduce rx overrurns seen while running bidirectional traffic.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
currently ath9k_hw_getchan_noise is not used anywhere
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
tx.c: In function ‘carl9170_tx_accounting_free’:
tx.c:159:28: warning: variable ‘txinfo’ set but not used
tx.c: In function ‘carl9170_tx_status_process_ampdu’:
tx.c:383:27: warning: variable ‘ar_info’ set but not used
tx.c: In function ‘__carl9170_tx_process_status’:
tx.c:626:27: warning: variable ‘arinfo’ set but not used
tx.c: In function ‘carl9170_tx_ampdu_queue’:
tx.c:1324:15: warning: variable ‘max’ set but not used
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Processing TSF out of range before RX helps to update beacon
timers so early in the succeeding rx process.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The assumsion is that while processing ath9k tasklet,
interrupts were already disabled and it will be enabled
at the completion of ath9k tasklet. But whenever TSFOOR is raised,
the driver configures the beacon timers after having received a
beacon frame from the AP which inturn enables the interrupts.
Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
With AR9003 at about ~ 10 feet from an AP that uses RTS / CTS you
will be able to associate but not not get data through given that
the power for the rates used was set too low. This increases the
power and permits data connectivity at longer distances from
access points when connected with HT40. Without this you will not
get any data through when associated to APs configured in HT40
at about more than 10 feet away.
Cc: stable@kernel.org
Cc: Fiona Cain <fcain@atheros.com>
Cc: Zhen Xie <Zhen.Xie@Atheros.com>
Cc: Kathy Giori <kathy.giori@atheros.com>
Cc: Neha Choksi <neha.choksi@atheros.com>
Cc: Wayne Daniel <wayne.daniel@atheros.com>
Cc: Gaurav Jauhar <gaurav.jauhar@atheros.com>
Cc: Samira Naraghi <samira.naraghi@atheros.com>
CC: Ashok Chennupati <ashok.chennupati@atheros.com>
Cc: Lance Zimmerman <lance.zimmerman@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
At present the noise floor calibration is processed in supported
control and extension chains rather than required chains.
Unnccesarily doing nfcal in all supported chains leads to
invalid nf readings on extn chains and these invalid values
got updated into history buffer. While loading those values
from history buffer is moving the chip to deaf state.
This issue was observed in AR9002/AR9003 chips while doing
associate/dissociate in HT40 mode and interface up/down
in iterative manner. After some iterations, the chip was moved
to deaf state. Somehow the pci devices are recovered by poll work
after chip reset. Raading the nf values in all supported extension chains
when the hw is not yet configured in HT40 mode results invalid values.
Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently, the driver only disable multicast filtering when the
FIF_ALLMULTI driver flag has been just set (ie,
if changed_flags& FIF_ALLMULTI and *new_flags& FIF_ALLMULTI) or else
it will reenable multicast filtering.
But next time, this condition will be false and multicast filtering
will be reenabled, even through FIF_ALLMULTI is still set.
This mean that allmulticast only works for less than two minutes in
ad-hoc mode. This patch fixes that to disable multicast filtering
as long as FIF_ALLMULTI is set.
Signed-off-by: Nicolas Cavallari <cavallar@lri.fr>
Acked-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
when aggregation protection mode is enabled the hardware needs
to send RTS/CTS for each HT frame. Currently its disabled so
remove the unused call backs.
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
While draining the txq in flush, the buffers can be
added into the tx queue by tx_tasklet which leads to
unneccesary chip reset.
This issue was originially found with AR9382 and
running heavy uplink udp traffic with higher bandwidth
and doing frequent bgscan.
Cc: stable@kernel.org
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Remove all the convoluted hacks in the driver and simplify things
by making use of mac80211's LED triggers.
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
CC [M] drivers/net/wireless/ath/ath5k/reset.o
drivers/net/wireless/ath/ath5k/reset.c: In function ‘ath5k_hw_init_core_clock’:
drivers/net/wireless/ath/ath5k/reset.c💯51: warning: ‘txf2txs’ may be used uninitialized in this function
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This callback is used to set the minimum rate for management
frames.
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch adds WMI_BITRATE_MASK_CMDID which can be
used by the set_bitrate_mask() handler.
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Bump the firmware version to 1.2
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use ps wrappers before accessing hw registers in btcoex.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Generic timer interrupt was not triggered unless autosleep was
disabled. Since autosleep is enabled in the newer chipsets,
enable generic timer for using with bt coex logic.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Move bt_stomp to ath9k_hw and add its support for latest chipsets.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Using the ieee80211_sta_block allows the PS code
to handle awake->doze->awake transitions of our
clients in a race-free manner.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The xpaBiasLvlFreq parameter array is made up of 16 bit words which
aren't byte-swapped like the other 16-bit eeprom parameters are.
It's only used by the AR9160.
Signed-off-by: Adrian Chadd <adrian@freebsd.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Requesting beacon sync up to configure beacon timers properly
in hw, has be done after doing beacon config with default values.
Setting the flags in beacon config is causing the device to not
enter into network sleep on idle state.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On AR9003 chips, doing three IQ calibrations will possibly cause chip
in stuck state. In noisy environment, chip could receive
a packet during the middle of three calibrations and it causes
the conflict of HW access and the eventual failure. It also
causes IQ calibration outliers which results in poor Tx EVM.
The IQ Cal procedure is after resetting the chip, run IQ cal 3 times
per each cal cycle and find the two closest readings and average of two.
The advantage of running Tx IQ cal more than once is that we can compare
calibration results for the same gain setting over multiple iterations.
Most of the cases the IQ failures were observed after first pass.
For the AR9485 and later chips, Tx IQ Calibration is performed along
with AGC cal. But for pre-AR9485 chips, Tx IQ cal HW has to be separated
from the rest of calibration HW to avoid chip hang. After all
calibrations are done in HW, we can start SW post-processing.
By doing this way, we minimize the SW difference among all chips.
The order of calibration (run IQ cal before other calibration) is also
needed to avoid chip hang for chips before AR9485. This issue was
originally observed with AR9382.
During the issue kernel log was filled with following message
ath: timeout (100000 us) on reg 0xa640: 0x00000001 & 0x00000001 != 0x00000000
ath: timeout (100000 us) on reg 0xa2c4: 0x00158dd9 & 0x00000001 != 0x00000000
ath: Unable to reset channel (2412 MHz), reset status -5
ath: Unable to set channel
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This helped the developers to fix an issue of chip not entering network
sleep during idle state, previously this was only available as a debug
message
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
newer chipsets support auto sleep feature, so remove the
unlikely check which does not seems to help anything
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Felix Fietkau
Rajkumar Manoharan
Christian Lamparter
Mohammed Shafi Shajakhan
Senthil Balasubramanian
Luis R. Rodriguez
Ben Greear
Javier Cardona
Nicolas Cavallari
Sujith Manoharan
John W. Linville
Vivek Natarajan
Adrian Chadd