Renamed to be in sync with Marketing term and to avoid
confusion with other chip names.
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The code for handling various restrictions concerning regulatory limits,
antenna gain, etc. is very convoluted and duplicated across various
EEPROM parsing implementations, making it hard to review.
This patch partially cleans up the mess by unifying regulatory limit
handling in one function and simplifying handling of antenna gain.
It also removes unused transmit power scaling arrays from the EEPROM code,
which belonged to an unimplemented API that isn't supposed to be in
the driver anyway.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Move the register macros to appropriate header files to be in
sync with other register definitions and also a single place
to refer everything.
Signed-off-by: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch adds support for AR946/8x chipets.
Signed-off-by: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Due to some recent optimization done in the way the mac address
bytes are written into the OTP memory, some AR9485 chipsets were
forced to use the first byte from the eeprom template and the
remaining bytes are read from OTP.
AR9485 happens to use generic eeprom template which has 0x1 as
the first byte causes issues in bringing up the card.
So fixed the eeprom template accordingly to address the issue.
Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Signed-off-by: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The commit ebefce3d13 failed
to set proper PMU value to address ripple issue for AR9485.
Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
CTL power data incorrect in ctlPowerData_2G field of ar9300_eeprom.
Setting incorrect CTL power in calibration is causing lower tx power.
Tx power was reported as 3dBm while operating in channel 6 HT40+/
in channel 11 HT40- due to CTL powers in the calibration is set to
zero.
Cc: stable@kernel.org
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use the previously calculated maximum of all rates instead of just the one
from the lowest rate of the selected PHY mode.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
when the AP is configured with HT40/2.4GHz and when PAPRD is enabled in station
we have PAPRD training frames never sent out because of the following
failure "PAPRD target power delta out of range". This consistently happens
in channel 10,11 in Over The Air testing and rarely in channel 6 under wired
setup.
the reason behind this issue is all the HT40 rates target power
are 0 when we operate in channel 10/11 at 2.4GHz
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is the same fix as
commit 841051602e
Author: Matteo Croce <technoboy85@gmail.com>
Date: Fri Dec 3 02:25:08 2010 +0100
The ath9k driver subtracts 3 dBm to the txpower as with two radios the
signal power is doubled.
The resulting value is assigned in an u16 which overflows and makes
the card work at full power.
in two more places. I grepped the ath tree and didn't find any others.
Cc: stable@kernel.org
Signed-off-by: Daniel Halperin <dhalperi@cs.washington.edu>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (39 commits)
b43: fix comment typo reqest -> request
Haavard Skinnemoen has left Atmel
cris: typo in mach-fs Makefile
Kconfig: fix copy/paste-ism for dell-wmi-aio driver
doc: timers-howto: fix a typo ("unsgined")
perf: Only include annotate.h once in tools/perf/util/ui/browsers/annotate.c
md, raid5: Fix spelling error in comment ('Ofcourse' --> 'Of course').
treewide: fix a few typos in comments
regulator: change debug statement be consistent with the style of the rest
Revert "arm: mach-u300/gpio: Fix mem_region resource size miscalculations"
audit: acquire creds selectively to reduce atomic op overhead
rtlwifi: don't touch with treewide double semicolon removal
treewide: cleanup continuations and remove logging message whitespace
ath9k_hw: don't touch with treewide double semicolon removal
include/linux/leds-regulator.h: fix syntax in example code
tty: fix typo in descripton of tty_termios_encode_baud_rate
xtensa: remove obsolete BKL kernel option from defconfig
m68k: fix comment typo 'occcured'
arch:Kconfig.locks Remove unused config option.
treewide: remove extra semicolons
...
* 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>
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>
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>
Change from the systems team to update PMU setting for AR9485
version of chipsets.
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The size of the eeprom data is 1088 bytes for AR9485. But
a sanity check is done against 4K which would result in a
'potential read past the end of the buffer' smatch complaint.
Reported-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The commit 'ath9k_hw: Disable PAPRD for rates with low Tx power' changed
the code that sets the PAPRD rate masks to use only either the HT20 mask
or the HT40 mask. This is wrong, as the hardware can still use HT20 rates
even when configured for HT40, and the operating channel mode does not
affect PAPRD operation.
The register for the HT40 rate mask is applied as a mask on top of the
other registers to selectively disable PAPRD for specific rates on HT40
packets only.
This patch changes the code back to the old behavior which matches the
intended use of these registers. While with current cards this should not
make any practical difference (according to Atheros, the HT20 and HT40
mask should always be equal), it is more correct that way, and maybe
the HT40 mask will be used for some rare corner cases in the future.
Cc: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Target Tx power available in eeprom is for PAPRD. If PAPRD
fails, paprd scale factor needs to be detected from this
target tx power.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When the drop in Tx power for a particular mcs rate exceeds
the paprd scale factor, paprd may not work properly. Disable
paprd for any such rates.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
