Standardize the logging macros used.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

All AR9003 features are now complete so enable AR9003
support.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We tried to squeeze as much AR9003 support into this kernel
release cycle but there are a few features which are still
being tested and developed. Some of these features are critical
to the stable operation of AR9003 so for now disable AR9003 support
all together. This will get re-enabled once all necessary features
are in place but very likely will not happen for 2.6.35.
Reviewed-by: NDon Breslin <don.breslin@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The first AR9003 hardware family device supported is the
AR9300, which has the vendor:device id 168c:0030
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This can be used to store the bus types ( AHB/PCI/USB ).
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
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>

Calling ath_bus_cleanup() after ieee80211_free_hw() resulted in access
to common->bus_ops, which is already freed as part of the device data.

Remove the cleanup field in struct ath_bus_ops, as it was never used
properly.  Remove ath_bus_cleanup().  Merge cleanup functions in place
of the ath_bus_cleanup() calls.  Take care not to use any device data
after ieee80211_free_hw().
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The device has to be marked as invalid before
registering the ISR. HW initialization takes place
after the ISR has been registered, and the invalid
flag is eventually cleared in the ->stop() callback.
Reported-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
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>

Use DEFINE_PCI_DEVICE_TABLE() so we get place PCI ids table into correct section
in every case.
Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The C99 specification states in section 6.11.5:

The placement of a storage-class specifier other than at the beginning
of the declaration specifiers in a declaration is an obsolescent
feature.
Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Devices with external radios have revisions which we can count on.
On single chip solutions these EEPROM values for these radio revision
also exist but are not meaningful as the radios are embedded onto the
same chip. Each single-chip device evolves together as one device.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

These are shared between ath9k and the future ath9k_htc driver.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

hw code should never use private driver data, but
sometimes we need a backpointer so just stuff it on
the common ath struct.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

PCI and debug code will not be shared between ath9k and
ath9k_htc, so make that code use the common read/write ops.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We disable ASPM when enabling bluetooth coexistance. Disabling
ASPM is a bus specific operation. In the future other buses may
support bluetooth coexistance, an example is USB. To this end
move the current routine which disables ASPM into pci.c, and declare
it the PCI bt_coex_prep() helper. Additionally, since ASPM is
a PCI-Express primitive ensure we don't ever try to muck with ASPM
registers on non PCI-express devices.

This also cleans up hw.c to not include bus specific headers or
utilities.

Cc: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Cc: Stephen Chen <stephen.chen@atheros.com>
Cc: Zhifeng Cai <zhifeng.cai@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This subsystem id will be used later to turn on the btcoex
support.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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

ath9k ahb requests an IRQ and indicates 'ath9k' claimed it,
ath9k pci requests an IRQ and indicates 'ath'   claims it;
since 'ath' is another module sync both ahb and pci to claim
the irq using 'ath9k'.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We've cleaned up ath_init_device() and its children enough
to pass meaninful errors back from probe. When this fails
it means our device could not be initialized and a meaninful
error will have been passed.

Do the same for request_irq() and also synchronize the error
messages while at it.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The -ENOMEM was never being passed on failure.
While at it use dev_err() as ahb does upon failure.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
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 fixes a bug where the device was enabled
before restoring the PCI state.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We re-label the device driver initialization routines from the
ath_softc, the "Software Carrier" fillers. This should make it
clearer what each of these do.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
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>

An earlier commit, 'ath9k: remove dummy PCI "retry timeout" fix', removed
code that was documented to disable RETRY_TIMEOUT register (PCI reg
0x41) since it was claimed to be a no-op. However, it turns out that
there are some combinations of hosts and ath9k-supported cards for
which this is not a no-op (reg 0x41 has value 0x80, not 0) and this
code (or something similar) is needed. In such cases, the driver may
be next to unusable due to very frequent PCI FATAL interrupts from the
card.

Reverting the earlier commit, i.e., restoring the RETRY_TIMEOUT
disabling, seems to resolve the issue. Since the removal of this code
was not based on any known issue and was purely a cleanup change, the
safest option here is to just revert that commit. Should there be
desire to clean this up in the future, the change will need to be
tested with a more complete coverage of cards and host systems.

http://bugzilla.kernel.org/show_bug.cgi?id=13483

Cc: stable@kernel.org
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch completely rewrites the rfkill core to address
the following deficiencies:

 * all rfkill drivers need to implement polling where necessary
   rather than having one central implementation

 * updating the rfkill state cannot be done from arbitrary
   contexts, forcing drivers to use schedule_work and requiring
   lots of code

 * rfkill drivers need to keep track of soft/hard blocked
   internally -- the core should do this

 * the rfkill API has many unexpected quirks, for example being
   asymmetric wrt. alloc/free and register/unregister

 * rfkill can call back into a driver from within a function the
   driver called -- this is prone to deadlocks and generally
   should be avoided

 * rfkill-input pointlessly is a separate module

 * drivers need to #ifdef rfkill functions (unless they want to
   depend on or select RFKILL) -- rfkill should provide inlines
   that do nothing if it isn't compiled in

 * the rfkill structure is not opaque -- drivers need to initialise
   it correctly (lots of sanity checking code required) -- instead
   force drivers to pass the right variables to rfkill_alloc()

 * the documentation is hard to read because it always assumes the
   reader is completely clueless and contains way TOO MANY CAPS

 * the rfkill code needlessly uses a lot of locks and atomic
   operations in locked sections

 * fix LED trigger to actually change the LED when the radio state
   changes -- this wasn't done before
Tested-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad]
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
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 the second go through of the old DMA_nBIT_MASK macro,and there're not
so many of them left,so I put them into one patch.I hope this is the last round.
After this the definition of the old DMA_nBIT_MASK macro could be removed.
Signed-off-by: NYang Hongyang <yanghy@cn.fujitsu.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Greg KH <greg@kroah.com>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

How time flies.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Remove the PCI retry timeout code as that was just taken from ipw2100
due to historical reasons but in reality its a no-op, additionally its
simply incorrect as each PCI devices has its own custom PCI configuration
space on PCI config space >= 0x40. Not to mention we were trying to write
0 to a place that already has 0 on it.

Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Ben Cahill <ben.m.cahill@intel.com>
Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Tested-by: NAdel Gadllah <adel.gadllah@gmail.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is the initial step in allowing ath9k to register multiple
virtual radios (wiphys). The goal of virtual radios is to allow the
same radio to be shared for multiple virtual interfaces that may
operate on different channels. The mac80211 virtual interface support
is designed only for single channel operation and as such, it is not
suitable for this type of use. Anyway, it can be used on top of the
virtual radio concept, if desired (e.g., use two virtual radios to
handle two channels and then add multiple mac80211 virtual interfaces
on top of each virtual radio).

The new struct ath_wiphy is now registered as the driver data
structure for wiphy. This structure has a pointer to the shared (among
virtual wiphys of the same physical radio) struct ath_softc data. The
primary wiphy maintains the allocated memory for ath_softc. Secondary
(virtual) wiphys will only allocate the new ath_wiphy structure.

Registration of secondary wiphys is added in a separate patch.
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

pci_release_region() has to be called after the device
has been disabled. Also remove a stray __init attribute.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

RX and calibration have different timeout requirements.
This patch fixes it by changing the HW wait routine
to accept a timeout value.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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

Finally, merge these structures and have a single
HW specific data structure.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch moves all the HW version/revision specific
information into a separate structure.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Split the core header files into manageable pieces.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On the AR913x SOCs we have to provide EEPROM contents via platform_data,
because accessing the flash via MMIO is not safe. Additionally different
boards may store the radio calibration data at different locations.

Changes-licensed-under: ISC
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NImre Kaloz <kaloz@openwrt.org>
Tested-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>