wifi: ath9k: Remove -Warray-bounds exception

GCC-12 emits false positive -Warray-bounds warnings with
CONFIG_UBSAN_SHIFT (-fsanitize=shift). This is fixed in GCC 13[1],
and there is top-level Makefile logic to remove -Warray-bounds for
known-bad GCC versions staring with commit f0be87c42cbd ("gcc-12: disable
'-Warray-bounds' universally for now").

Remove the local work-around.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679

Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20221006192054.1742982-1-keescook@chromium.org

wifi: ath9k: silence array-bounds warning on GCC 12

GCC 12 says:

drivers/net/wireless/ath/ath9k/mac.c: In function ‘ath9k_hw_resettxqueue’:
drivers/net/wireless/ath/ath9k/mac.c:373:22: warning: array subscript 32 is above array bounds of ‘struct ath9k_tx_queue_info[10]’ [-Warray-bounds]
373 | qi = &ah->txq[q];
| ~~~~~~~^~~

I don't know where it got the 32 from, relegate the warning to W=1+.

Acked-by: Kalle Valo <kvalo@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

ath9k: add loader for AR92XX (and older) pci(e)

Atheros cards with a AR92XX generation (and older) chip usually
store their pci(e) initialization vectors on an external eeprom chip.
However these chips technically don't need the eeprom chip attached,
the AR9280 Datasheet in section "6.1.2 DEVICE_ID" describes that
"... if the EEPROM content is not valid, a value of 0xFF1C returns
when read from the register". So, they will show up on the system's
pci bus. However in that state, ath9k can't load, since it relies
on having the correct pci-id, otherwise it doesn't know what chip it
actually is. This happens on many embedded devices like routers
and accesspoint since they want to keep the BOM low and store the
pci(e) initialization vectors together with the calibration data
on the system's FLASH, which is out of reach of the ath9k chip.

Furthermore, Some devices (like the Cisco Meraki Z1 Cloud Managed
Teleworker Gateway) need to be able to initialize the PCIe wifi device.
Normally, this should be done as a pci quirk during the early stages of
booting linux. However, this isn't possible for devices which have the
init code for the Atheros chip stored on NAND in an UBI volume.
Hence, this module can be used to initialize the chip when the
user-space is ready to extract the init code.

Martin Blumenstingl prodived the following fixes:
owl-loader: add support for OWL emulation PCI devices
owl-loader: don't re-scan the bus when ath9k_pci_fixup failed
owl-loader: use dev_* instead of pr_* logging functions
owl-loader: auto-generate the eeprom filename as fallback
owl-loader: add a debug message when swapping the eeprom data
owl-loader: add missing newlines in log messages

Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath: fix SPDX tags

Commit ec8f24b7faaf ("treewide: Add SPDX license identifier -
Makefile/Kconfig") marked various Makefiles and Kconfig files within ath
directories as GPL-2.0. But these modules and drivers are actually ISC:

* ath
* ar5523
* ath10k
* ath5k
* ath6kl
* ath9k
* wcn36xx
* wil6210

Fix SPDX tags accordingly.

Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath9k: move spectral scan support under a separate config symbol

At the moment, spectral scan support, and with it RELAY, is always enabled
with ATH9K[_HTC]_DEBUGFS. Spectral scan support is currently the only user
of RELAY in ath9k, and it unconditionally reserves a relay channel.

Having debugfs support in ath9k is often useful even on very small embedded
routers, where we'd rather like to avoid the code size and RAM usage of the
relay support.

Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.

For non */uapi/* files that summary was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139

and resulted in the first patch in this series.

If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930

and resulted in the second patch in this series.

- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:

SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1

and that resulted in the third patch in this series.

- when the two scanners agreed on the detected license(s), that became
the concluded license(s).

- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.

- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).

- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.

- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct

This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.

Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ath9k: move RELAY and DEBUG_FS to ATH9K[_HTC]_DEBUGFS

Currently, the common ath9k_common module needs to have a
dependency on RELAY and DEBUG_FS in order to built. This
is usually not a problem. But for RAM and FLASH starved
AR71XX devices, every little bit counts.

This patch adds a new symbol CONFIG_ATH9K_COMMON_DEBUG
which makes it possible to drop the RELAY and DEBUG_FS
dependency there and move it to ATH_(HTC)_DEBUGFS.

Note: The shared FFT/spectral code (which is the only user
of the relayfs in ath9k*) needs DEBUG_FS to export the relayfs
interface to dump the data to userspace. So it makes no sense
to have the functions compiled in, if DEBUG_FS is not there.

Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

ath9k: feeding entropy in kernel from ADC capture

This patch is derived from
commit 6301566e0b2d ("ath9k: export HW random number generator"),

We evaluated the entropy of the ADC data on QCA9531, QCA9561, QCA955x,
and AR9340, and it has sufficient quality random data (at least 10 bits
and up to 22 bits of min-entropy for a 32-bit value). We conservatively
assume the min-entropy is 10 bits out of 32 bits. Thus, ATH9K_RNG_BUF_SIZE
is set to 320 (u32) i.e., 1.25 kilobytes of data is inserted to fill up
the pool as soon as the entropy counter becomes 896/4096 (set by random.c).
Since ADC was not designed to be a dedicated HW RNG, we do not want to bind
it to /dev/hwrng framework directly. This patch feeds the entropy directly
from the WiFi driver to the input pool. The ADC register output is only
used as a seed for the Linux entropy pool. No conditioning is needed,
since all the conditioning is performed by the pool itself.

Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

Revert "ath9k: export HW random number generator"

This reverts commit 6301566e0b2dafa7d6779598621bca867962a0a2. Oleksij Rempel
noticed that the randomness doesn't look to be good enough and Stephan Mueller
commented:

"I would say that the discussed RNG does not seem fit for hooking it up with the
hwrandom framework."

http://lkml.kernel.org/g/3945775.m5HblJPgiO@tauon.atsec.com

So let's the revert the patch until we are sure that we can trust this random
generator.

Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath9k: export HW random number generator

We measured the FFT-based entropy in 3 ways, Shannon entropy,
collision entropy, and directly measured min-entropy. Just to
be conservative, we recommend the estimated min-Entropy to be
10 bits per 16-bit value.

Analysis was done by Jacobson,David(djacobso@qti.qualcomm.com).

Signed-off-by: Miaoqing Pan <miaoqing@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath9k: Register private AIC ops

AIC can be disabled or enabled on a per-card
basis using MCI configuration, so register a function
to check its status.

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

ath9k: move spectral.* to common-spectral.*

and rename exports from ath9k_spectral_* to ath9k_cmn_spectral_*

Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: make support for PC-OEM cards optional

The initvals use up quite a bit of space, and PC-OEM support is
typically not needed on embedded systems

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

ath9k: add config for (en|dis)abling ACK timeout estimation

Add ACK timeout estimation algorithm to ath9k Makefile and Kconfig

Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: Add channel context structure

The channel context structure is defined to enable
multi-channel concurrency support.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k-common: create common-debug and move modal_eeprom to cmn

Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: move ath9k_beacon_config_sta to common-beacon

Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: move ath9k_init_channels_rates to common-init

and rename it to ath9k_cmn_init_channels_rates.
sbands are move to ath_common as well.

Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: Remove ath9k rate control

There is no benefit in retaining the legacy rate control module
in the driver codebase.

It is known to be buggy and has less than optimal performance
in real-world environments compared with minstrel. The only
reason that it was kept when we made the switch to minstrel
as default was that it showed higher throughput numbers in a
clean/ideal environment.

This is no longer the case and minstrel can push ath9k to
the same throughput levels. In TCP, with 3-stream cards, more than
295 Mbps can be obtained in open air, with 2-stream cards,
210 Mbps is easily reached. To test performance issues,
instead of using a broken rate control module, it is better
to use the fixed-rate interface provided by mac80211 anyway.

The ath9k RC has not received any bug fixes in years and is
just bit-rotting away - this patch removes it.

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: Add an option for station statistics

Also, rename node_stat to node_aggr.

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: Cleanup spectral scan code

* Move definitions to spectral.h
* Move processing/debug code to spectral.c

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: Use CONFIG_ATH9K_WOW

Move the WoW code to wow.c and compile it conditionally
based on CONFIG_ATH9K_WOW.

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: Fix wow.c compilation

The HW routines to set various WoW registers are present
in wow.c. For some reason, it has been compiled as part
of the main ath9k.ko module all this time, when it should
really be part of ath9k_hw.ko. This patch renames the file to
ar9003_wow.ko and adds it to ath9k_hw.ko.

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: Fix TX99 config option usage

Use CONFIG_ATH9K_TX99 to properly enclose the tx99 code
and make sure that it is not compiled as part of the driver
when it is not selected. Move the tx99 code to a new file tx99.c
and also add ATH9K_DEBUGFS as a dependency in Kconfig.

This reduces the module size on platforms like OpenWrt where
ATH9K_DEBUGFS is selected, but TX99 might be disabled.

Cc: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k/ath: move dfs pattern detector to ath

Move the DFS pattern detector code to the ath module so
the other Atheros drivers can make us of it. This makes
no functional changes.

Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Reviewed-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: Use minstrel rate control by default

The ath9k rate control algorithm has various architectural
issues that make it a poor fit in scenarios like congested
environments etc.

An example: https://bugzilla.redhat.com/show_bug.cgi?id=927191

Change the default to minstrel which is more robust in such cases.
The ath9k RC code is left in the driver for now, maybe it can
be removed altogether later on.

Cc: stable@vger.kernel.org
Cc: Jouni Malinen <jouni@qca.qualcomm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: Add hardware code for WoW

add a new file wow.c which takes care of the hardware code
for WoW.

*program the descriptors and data words to periodically
send Keep Alive Frames.
*program the user defined patterns/masks and pattern length
in the hardware registers.
*'ath9k_hw_wow_enable' is called during the drivers suspend
callback which takes care of the following
- tracking wow event mask (to suppress spurious
wow events)
- properly configure suspend/resume WAR registers
- configure PCIE PM control register
- configure MAC WoW registers and their timeouts
- enabling wow configuration like magic packet,
user patterns based on users configuration
- configuring timeouts for KAL, beacon miss,
aifs, slot time, backoff
- create Keep Alive Pattern ('KAL')
*'ath9k_hw_wow_wakeup' is called during the drivers resume
callback which takes care of the following
- primary task is to find the reason for wakeup
from the wow status register
- configure/restore AR_PCIE_PM_CTRL register
- clear all WoW events
- configure/restore suspend/resume WAR registers

Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Cc: vadivel@qca.qualcomm.com
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: Move LNA code to antenna.c

And use a helper function to setup antennae after a reset.

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: Group link monitoring logic

Add link.c and move all the link/connection monitoring
code to it.

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: add DFS pattern detector

This adds a DFS pattern detector to ath9k. It is fed with pulse events
by the radar pulse detector and reports in place whether a pattern
was detected. On detection, the result is reported as radar event to
the DFS management component in the upper layer.

Currently the ETSI DFS domain is supported with detector lines for
the patterns defined by EN-301-893 v1.5.1. Support for FCC and JP
will be added gradually.

To include the pattern detector, ath9k must be built with support
for DFS certified config flag set (CONFIG_ATH9K_DFS_CERTIFIED).

Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: Use CONFIG_ATH9K_BTCOEX_SUPPORT

Make use of CONFIG_ATH9K_BTCOEX_SUPPORT in ath9k_hw
to provide a clean way of compilation without BTCOEX
support.

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: Use CONFIG_ATH9K_BTCOEX_SUPPORT

This patch uses CONFIG_ATH9K_BTCOEX_SUPPORT to conditionally
compile btcoex-related code in the driver core.

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: add DFS radar pulse processing

This initial DFS module provides basic functionality to deal
with radar pulses reported by the Atheros DFS HW pulse detector.

The reported data is evaluated and basic plausibility checks
are performed to filter false pulses. Passing radar pulses are
forwarded to pattern detectors which are not yet implemented.

(Some modifications to actually use ATH9K_DFS_DEBUGFS based on comments
from Julian Calaby <julian.calaby@gmail.com>. -- JWL)

Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: Add MCI h/w code and state machine

Cc: Wilson Tsao <wtsao@qca.qualcomm.com>
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: Add btcoex profile management support for AR9462

AR9462 chips have the capabilities to provoide bluetooth
profile information. For non-AR9462 btcoex chips, the BT
priority traffic was identified by periodically polling
the respective registers and updated dutycycle, stomptype,
etc. As AR9462 chip offers the BT profile informations,
let us make use of that to update aggregation limit,
dutycycle, stomptype and wieghtages.

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

ath9k_hw: Add radio retention support for AR9480

Supported calibrations of radio retention table (RTT) are
- DC offset
- Filter
- Peak detect

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

ath9k_htc: Move debug code to a separate file

Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: introduce ATH9K_{PCI,AHB} config options

Currently ath9k only available in menuconfig if PCI bus
support is enabled. However the driver is required for
the built-in wireless MACs of the Atheros AR9130/AR9132
SoCs. These SoCs have no PCI controller, the wireless
MAC is connected to the AHB bus on them.

Introduce separated config options for the supported
buses, in order to allow building of ath9h without PCI
bus support.

As a bonus, this patch removes the cross-reference of
the ATHEROS_AR71XX option which is not present in the
kernel.

Cc: Luis R. Rodriguez <lrodriguez@atheros.com>
Cc: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: remove support for virtual wiphys

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

ath9k: make the driver specific rate control module optional

ath9k can use minstrel_ht instead, so it makes sense to save some space here.

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

ath9k_htc: Add support for bluetooth coexistence.

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

ath9k_hw: add functions for controlling PA predistortion calibration

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

ath9k_hw: move AR9002 mac ops to its own file

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: Implement AR9003 eeprom callbacks

Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: split the generic hardware code by hardware family

Move out the generic hardware family code out into their own
files, we have one for AR5008, AR9001, and AR9002 family (ar9002_hw.c)
and another file for the new AR9003 hardware family (ar9003_hw.c).

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: split calib code by hardware families

Calibration code touches phy registers and since these
change the calibration code needs to be abstracted.

Noise floor calibration is the only thing remaining but
since the remaining calls only touch the AR_PHY_AGC_CONTROL
register we'll just define that register conditionally, that
will be done separately. The goal is to remove the dependency
of ar9002_phy.h on calib.c

This also adds stubs to be filled for AR9003 calibration code.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: Fill rx_enable() for the AR9003 hardware family

Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: Add AR9003 PHY support

This add stubs for PHY support for the AR9003 hardware family.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_hw: Move some RF ops to the private callbacks

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: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k_htc: Support for AR9271 chipset.

Features:

* Station mode
* IBSS mode
* Monitor mode
* Legacy support
* HT support
* TX/RX 11n Aggregation
* HW encryption
* LED
* Suspend/Resume

For more information: http://wireless.kernel.org/en/users/Drivers/ath9k_htc

Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: Add new file init.c

Move initialization/de-initialization related
code to this file.

Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: Add a new file for GPIO

Move all LED/RFKILL/BTCOEX related code
to gpio.c

Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: separate debugfs support from CONFIG_ATH_DEBUG

In my setups, ath9k's debugfs files are most of the time much more
useful than the messages generated by enabling CONFIG_ATH_DEBUG along
with the right debug flags.
Since CONFIG_ATH_DEBUG comes with a noticeable overhead on embedded
systems, this patch makes it possible to use the debugfs files without
that option.

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

ath9k_common: add new module to share 802.11n driver helpers

ath9k and ath9k_htc share a lot of common hardware characteristics.
They only differ in that ath9k_htc works with a target CPU and ath9k
works directly with the hardware. ath9k_htc will do *some* things in
the firmware, but a lot of others on the host.

The common 802.11n hardware code is already shared through the ath9k_hw
module. Common helpers amongst all Atheros drivers can use the ath module,
this includes ath5k and ar9170 as users. But there is some common driver
specific helpers which are not exactly hardware code which ath9k and
ath9k_htc can share. We'll be using ath9k_common for this to avoid
bloating the ath module and the common 802.11n hardware module ath9k_hw.

We start by sharing skb pre and post processing in preparation for a hand
off to mac80211.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: move hw code to its own module

hw code for Atheros 802.11n hardware is commmon between
different chipsets. This moves this code into a separate
module, the next expected user of this code will be
the ath9k_htc module.

The ath9k/ dir is now selected by ATH9K_HW, an option which
gets selected by either ath9k or ath9k_htc, but remains
invisible for user menuconfig configuration. If either
ath9k or ath9k_htc will be compiled into the kernel
ath9k_hw will also be compiled in.

Cc: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

atheros: move bus ops to ath_common

This is the last part to make ath9k hw code core driver agnostic.
I believe ath9k_htc can now use use the hw code unmodified.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: move ATH9K_RSSI_BAD to hw.h

mac.c is now core driver independent.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: clarify what hw code is and remove ath9k.h from a few files

hw code will be shared between ath9k and ath9k_htc.
Just a few more files are left to clean up, mark them as well.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: Move btcoex stuff from hw.[ch] to new btcoex.[ch]

Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: Split eeprom.c into manageable pieces

Add eeprom_def.c, eeprom_4k.c and eeprom_9287.c
This improves maintainability.

Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

atheros: put atheros wireless drivers into ath/

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>