The Walsh bit is disabled for regulatory consideration.

FCC limit for walsh enable is lower than that for walsh disable. So
disabling walsh bit will not limit tx power/affect tx power even in
cases where we are not FCC limited (most client cards). If the tx
power is not FCC limited, then enabling/disabling walsh bit will
not affect Avg. EVM/overall performance in any visible manner.

Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In congested network, having all rate reties at MCS rates
is failing to transmit the frame offenly. By the time reaching
the success rate set, the application gets timed out. One such
scenario is that authentication time out during 4-Way handshake.
This patch uses a legacy rate as last retry sequnce for
unaggregated frames or if the first selected rate's PER is ~80%
of max limit. And also observed from the tx status that the frame
was trasmitted successfully by using legacy rates.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Cc: stable@kernel.org
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

this useful for debugging and to keep track of success/failure of
frames such as ACK, RTS and FCS error count in a noisy environment
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The firmware keeps track of channel usage. This data can
be used by the automatic channel selection to find the best
channel.

Survey data from wlan4
	frequency:				5200 MHz [in use]
	noise:					-91 dBm
	channel active time:			811909 ms
	channel busy time:			63395 ms
	channel transmit time:			59636 ms
Survey data from wlan4
	frequency:				5210 MHz
	noise:					-91 dBm
	channel active time:			121 ms
	channel busy time:			119 ms
	channel transmit time:			0 ms
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Prevent 8 bytes from being truncated from MGMT packets
when using TKIP.
Signed-off-by: NBill Jordan <bjordan@rajant.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We have resolved all the known issues with DMA mode, however some users
(or distros) are still forcing PIO mode by config files. Without
debugging enabled it's not noticable at all. Add the warning for them.

Cc: Gregory Bellier <gregory.bellier@gmail.com>
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The EIFS value read from AR_D_GBL_IFS_EIFS register in core clocks and then
written back as microsecond value.
Signed-off-by: NAlex Hacker <hacker@epn.ru>
Acked-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

All AR9170 hardware have a 16-Bit random number generator.
The documentation claims the values are suitable for
"security keys".

The "throughput" is around 320Kibit/s. It's slow, but it
does work without introducing any special offload
firmware commands.
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The firmware keeps track of channel usage. This data can
be used by the automatic channel selection to find the
*best* channel.

Survey data from wlan22
	frequency:                      2412 MHz [in use]
	noise:                          -86 dBm
	channel active time:            3339608 ms
	channel busy time:              270982 ms
	channel transmit time:          121515 ms
Survey data from wlan22
	frequency:                      2417 MHz
	noise:                          -86 dBm
	channel active time:            70 ms
	channel busy time:              2 ms
	channel transmit time:          1 ms
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Import new headers from our firmware branch:
git://git.kernel.org/pub/scm/linux/kernel/git/chr/carl9170fw.gitSigned-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

AR9170_PWR_REG_PLL_ADDAC is used to set the main clock
divisor which affects the AHB/CPU speed. Because this
would interfere with the firmware internal timekeeping,
the function has to be moved into the firmware.
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There was an extra semicolon so the if condition wasn't used.  We
checked "priv->dev" twice instead of "priv->mesh_dev".
Signed-off-by: NDan Carpenter <error27@gmail.com>
Acked-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

They were taken from MMIO dump with few RegExps and vim.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Analog is switched on right after reading PHY version:
 read16 0xfaafc3e0 -> 0xa801
 phy_read(0x043b) -> 0x0000
phy_write(0x043b) <- 0x0000
Switched off after after killing radio:
>>> Switch Radio(OFF) end
 phy_read(0x043c) -> 0x0000
phy_write(0x043c) <- 0x0007
 phy_read(0x043b) -> 0x0000
phy_write(0x043b) <- 0x0007
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

wl reads radio version, then disables it. That's how we found it in MMIO
dump:
 radio_read(0x0000) -> 0x0031 <-- RADIO READ WITHOUT 0x200 SET!
 radio_read(0x0001) -> 0x0064 <-- RADIO READ WITHOUT 0x200 SET!
 radio_read(0x0002) -> 0x0020 <-- RADIO READ WITHOUT 0x200 SET!
 read32 0xfaafc120 -> 0x04000400
 phy_read(0x044d) -> 0x0000
phy_write(0x044d) <- 0x0000
 phy_read(0x044c) -> 0x1fff
phy_write(0x044c) <- 0x1fff
 phy_read(0x04b7) -> 0x0000
phy_write(0x04b7) <- 0x0000
 phy_read(0x04b1) -> 0x0000
phy_write(0x04b1) <- 0x0000
 phy_read(0x04b0) -> 0x7dff
phy_write(0x04b0) <- 0x7dff
 phy_read(0x04fa) -> 0x0000
phy_write(0x04fa) <- 0x0000
 phy_read(0x04f9) -> 0x007f
phy_write(0x04f9) <- 0x007f
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some hardware with 64-bit DMA uses lower address word for setting
routing (translation) bit. Add workaround for such boards.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On embedded hardware it's normal to not have a PCI device for the PCI
bridge that the wifi card is attached to. pdev->bus->self will be
NULL in that case. In that case, simply return without emitting an
useless kernel stack trace.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Debugfs file location:
<debugfs_mnt>/ieee80211/phy#/ath9k/dump_nfcal
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

While switching b/w HT20/40, the current channel's nf values
are updated into history buffer. Since the current channel's
channel type, channel flag got updated before reading
nf value from hw. This channel type mismatch is causing invalid
readings when hw is on ht20 but getnf tries to read on extn chains.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Before doing hw reset the current channel's noisefloor readings
are updated into history buffer. The extension chain's readings
are considered only if the current channel was configured in HT40.
While moving from HT40 to HT20, the extn chain's readings are
skipped though the current channel is in ht40. This patch updates
extn chain reading based on channel flag.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The chainmasks were already configured at process_ini
before doing init calibration.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Once RXEOL was disabled, it never be enabled again. This patch
re-enables rxeol at the end of rx tasklet.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Whenever RXEOL is received, both RXORN and RXEOL got cleared
to avoid rx overrun interrupt storm. This was handled only for
edma chips. The same scenario was also observered with AR9280,
doing frequent channel type switch b/w HT20/40 with bidi traffic
that is causing failure to stop rx dma. This patch clears
the RXEOL & RXORN interrupts for all chips.

ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42000020
DMADBG_7=0x000062c0
ath: Could not stop RX, we could be confusing the DMA engine when we
start RX up
------------[ cut here ]------------
WARNING: at drivers/net/wireless/ath/ath9k/recv.c:532
ath_stoprecv+0x110/0x120 [ath9k]()
Call Trace:
 [<ffffffff8104a55a>] warn_slowpath_common+0x7a/0xb0
 [<ffffffff8104a5a5>] warn_slowpath_null+0x15/0x20
 [<ffffffffa0560380>] ath_stoprecv+0x110/0x120 [ath9k]
 [<ffffffffa055e6fa>] ath_reset+0x6a/0x200 [ath9k]
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The WAR which adds extra delimiters when using RTS/CTS
with aggregation and non-enterprise AR9003 chips.
This extra padding is done after doing all the 4ms limit
checks and hence the total aggregate sizes are exceeding
the allowed duration. This patch limits the aggregate
sizes appropriately after including these extra delimiters.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Sometimes we need to write table which is 2-10 elements long. It's
easier to create such a function instead of defining array every time.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

No need to recompile the module anymore to set the debug level.
Signed-off-by: NStefan Assmann <sassmann@kpanic.de>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

MMIO hacks were used to trick ndis&wl. For example following:
 phy_read(0x0280) -> 0xffff
phy_write(0x0280) <- 0xff3e
***
 phy_read(0x0280) -> 0x0000
phy_write(0x0280) <- 0x003e
was translated to mask 0xff00 and set 0x3e.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>