The PLL control computation used to program the AR_RTC_PLL_CONTROL
register varies between our harware so just add a private callback for it.
AR9003 will use its own callback.
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>

This is not required for the AR9003 family.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The PHY split is easier done in a few steps. First move
the RF ops to the private ops and rename them accordingly.
We split PHY stuff up first for the AR5008 and AR9002
families. There are some callbacks that AR9002 share
with the AR5008 familiy so we set those first, if AR9002
has some different callbacks it will override them upon
hardware init.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is used only once by ath9k_hw_process_ini() to
write an array of phy registers through REG_WRITE_ARRAY(),
but we already call REG_WRITE_ARRAY() multiple times
on the same caller so just remove this pointless wrapper.
We'll eventually just move the ath9k_hw_process_ini()
caller as an callback to abstract away between different
hardware families.

Although this change is subtle I should note that this
does change the delay pattern on writing the next series
of registers. REG_WRITE_ARRAY() uses a counter for each
register write and does a udelay(1) every 64 writes. By
removing this call it means that the counter is processed
for all the iniBB_RfGain registers and is incremented
on ath9k_hw_process_ini(), before this the after the call
ath9k_hw_write_regs() was made the register counter was
kept at the same index number prior to the call.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

AR9003 does not have a reset control for AHB.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ath9k supports the AR5008, AR9001 and AR9002 family of Atheros
chipsets, all 802.11n. The new breed of 802.11n chips, the
AR9003 family will be supported as well soon. To help with its
support we're going to add a few callbacks for hardware routines
which differ considerably instead of adding branch checks for
the revision at runtime.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Don't modify ah->iniModes, it's supposed to be constant.  Instead, apply
the fixup when the data is written to the registers.

Change ath9k_hw_init_eeprom_fix() to only determine whether the fixup is
needed.

This allows similteneous support for AR9220 cards that need AR_AN_TOP2
fixup (such as Ubiquiti SR71-12) and those that don't need it (D-Link
DWA-552 rev A2).
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch adds support for a modified newer version of AR9285
chipsets.
Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

For USB devices, this check is invalid.
Remove the check so that new product IDs can be added.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ah->mask_reg was used to hold different data throughout the driver.
ath9k_hw_init_interrupt_masks() used it to save the value written to
AR_IMR.  ath9k_hw_set_interrupts() used it to hold the interrupt mask as
defined in enum ath9k_int.  Those masks differ in many bits.

Use ah->imask instead of ah->mask_reg in ath9k_hw_set_interrupts() and
ath9k_hw_updatetxtriglevel().  That's what the code was meant to do.
ah->imask is initialized in ath9k_start(), so we don't need to
initialize it from ah->mask_reg.

Once it's done, ah->mask_reg becomes write-only, so it's replaced with a
local variable in ath9k_hw_init_interrupt_masks().
Signed-off-by: NPavel Roskin <proski@gnu.org>
Reported-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Without this you will get a panic if the device initialization
fails. Also, free ath_hw instance properly. ath9k_hw_deinit()
shouldn't do it.

Cc: stable@kernel.org
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

AR9271 needs a full reset only upon the first reset, add
a call for the driver to enable these special resets. We
can optimize this out later without an export.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When initializing the PLL on AR9271 we always need
to set the core clock to 117MHz. While at it remove
the baud rate settings for the serial device on the
AR9271, the default settings work well unless you
want to customize it.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

After telling the AR9271 to go into full sleep we do not need
to clear the RTC reset signal.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The chip test is not required for AR9271 on the host driver
code as the firmware will do the test internally on its own.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Assign the proper number of GPIO pins for AR9271.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Update the register initialization values for AR9271.
This is based on our last review from our systems team.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The AR_IMR_S2 register sometimes cannot be read correctly.  Instead of a
valid value, 0xdeadbeef is returned.  The driver has been observed
writing that value back to AR_IMR_S2 after changing a few bits.

Cache the register value in ah->imrs2_reg and always write chached value
to the register.
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

While ath9k does not support RIFS yet, the ability to receive RIFS
frames is currently enabled for most chipsets in the initvals.
This is causing baseband related issues on AR9160 and AR9130 based
chipsets, which can lock up under certain conditions.

This patch fixes these issues by overriding the initvals, effectively
disabling RIFS for all affected chipsets.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Acked-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Adding support for setting the coverage class in some cases broke
association and data transfer, as it overwrote the initial ACK timeout
value from the initvals with a smaller value.
I don't know why the new value works in 5 GHz (matches the initval
there), but not in 2.4 GHz (initvals use 64us here), so until the
problem is fully understood, the value should be increased again.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some single chip family devices are sold in the market with
802.11n bonded out, these have no hardware capability for
802.11n but ath9k can still support them. These are called
AR2427.

Cc: stable@kernel.org
Reported-by: NRolf Leggewie <bugzilla.kernel.org@rolf.leggewie.biz>
Tested-by: NBernhard Reiter <ockham@raz.or.at>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Among other changes, this commit:

   commit 06d0f066
   Author: Sujith <Sujith.Manoharan@atheros.com>
   Date:   Thu Feb 12 10:06:45 2009 +0530

   ath9k: Enable Fractional N mode

changed the hw attach code to fix up initialization values only for
dual band devices, however the commit message did not give a reason as
to why this would be useful or necessary.

According to tests by Jorge Boncompte, this breaks at least some
2GHz-only cards, so the code should be changed back to the
unconditional INI fixup.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Reported-by: NJorge Boncompte <jorge@dti2.net>
Cc: stable@kernel.org
Tested-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Previously ath9k left the initialization of slot timing and ACK/CTS
timeout to the mode specific initvals. This does not handle short vs
long slot in 2.4 GHz and uses a rather strange value for the 2.4 GHz
ACK timeout (64 usec).
This patch uses the proper ath9k_hw functions for setting slot time and
timeouts and also implements the switch between short and long slot
time in 2.4 GHz
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The device initialization and termination functions
were messy and convoluted. Introduce helper functions
to clarify init_softc() and simplify things in general.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ath9k currently supports only RX interrupt
mitigation.
Signed-off-by: NSujith <Sujith.Manoharan@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>

Currently, the 2GHz band is enabled unconditionally, even if the device
does not support it.

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

Atheros single stream AR9285 and AR9271 have half the PCU TX FIFO
buffer size of that of dual stream devices. Dual stream devices
have a max PCU TX FIFO size of 8 KB while single stream devices
have 4 KB. Single stream devices have an issue though and require
hardware only to use half of the amount of its capable PCU TX FIFO
size, 2 KB and this requires a change in software.

Technically a change would not have been required (except for frame
burst considerations of 128 bytes) if these devices would have been
able to use the full 4 KB of the PCU TX FIFO size but our systems
engineers recommend 2 KB to be used only. We enforce this through
software by reducing the max frame triggger level to 2 KB.

Fixing the max frame trigger level should then have a few benefits:

  * The PER will now be adjusted as designed for underruns when the
    max trigger level is reached. This should help alleviate the
    bus as the rate control algorithm chooses a slower rate which
    should ensure frames are transmitted properly under high system
    bus load.

  * The poll we use on our TX queues should now trigger and work
    as designed for single stream devices. The hardware passes
    data from each TX queue on the PCU TX FIFO queue respecting each
    queue's priority. The new trigger level ensures this seeding of
    the PCU TX FIFO queue occurs as designed which could mean avoiding
    false resets and actually reseting hw correctly when a TX queue
    is indeed stuck.

  * Some undocumented / unsupported behaviour could have been triggered
    when the max trigger level level was being set to 4 KB on single
    stream devices. Its not clear what this issue was to me yet.

Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Cc: Bennyam Malavazi <bennyam.malavazi@atheros.com>
Cc: Stephen Chen <stephen.chen@atheros.com>
Cc: Shan Palanisamy <shan.palanisamy@atheros.com>
Cc: Paul Shaw <paul.shaw@atheros.com>
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch changes ath9k to pass proper MCS indexes and flags
between the RC and the rest of the driver code.
sc->cur_rate_table remains, as it's used by the RC code internally,
but the rest of the driver code no longer uses it, so a potential
new RC for ath9k would not have to update it.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Check for AR5416 ver 1.0 before calibrating 3 chains
for multi-chain. This is a WAR for calibration
failure.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ATH9K_ANT_VARIABLE is the default diversity control used.
Consequently ath9k_hw_decrease_chain_power() does nothing.
ath9k_hw_setantennaswitch() is unused too.

Also, gbeacon_rate is unused.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This will be shared between ath9k and ath9k_htc.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Force bias is a fix for usage of AR5416 radios on the 2.4 GHz band
for orientation sensitivity. This was only partially implemented
with the ath9k_hw_decrease_chain_power() but first -- this was being
called for all chipsets which is not correct and second -- it was
missing the actual orientation code.

We now ensure to only enable force bias only for AR5416 and BUG_ON()
on other chipsets. Although ath9k_hw_decrease_chain_power() was enabled
for newer chipsets I suspect that it never ran unless the EEPROM had
ATH9K_ANT_FIXED_A or ATH9K_ANT_FIXED_B for antenna diversity.
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>

This only differs between single-chip solutions and non single-chip
solutions.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This reorders phy.c routines in the order in the order in which they are used
and also moves the spur mitigation helpers for each type of chip into phy.c
as they are RF related.

This patch has no functional changes.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>