Everything including this header includes net/cfg80211.h, which
includes linux/netdevice.h, which includes linux/ethtool.h already.  Why
slow-down the build, even a little bit?
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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

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

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

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

Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Also sorts all "source" lines in the wireless/Kconfig.
Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Simplify the suspend and resume callbacks of ath5k by converting the
driver to struct dev_pm_ops and allowing the PCI PM core to do the
PCI-specific suspend/resume handling.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Set firmware and hardware version in wiphy so that user space can access
it.

(Modification from original in favor of cfg80211 ethtool support. -- JWL)

Cc: Kalle Valo <kalle.valo@iki.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

It's useful to provide firmware and hardware version to user space and have a
generic interface to retrieve them. Users can provide the version information
in bug reports etc.

Add fields for firmware and hardware version to struct wiphy.

(Dropped nl80211 bits for now and modified remaining bits in favor of
ethtool. -- JWL)

Cc: Kalle Valo <kalle.valo@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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

Both 1000 & 6000 series NICs contain on-chip OTP memory that
replaces the off-chip EEPROM memory. The nature of OTP means
there is a limited number of times a particular board can go through the
factory flow and be (re)calibrated. As a consequence there will be some boards
that contain EEPROM memory because OTP blocks were full.

In the signature validation routine, iwlwifi needs to make sure
"select bit" and "EEPROM/OTP signature" agree on the type of
NVM to be used to configure the system.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Replace iwl_poll_direct_bit with iwl_poll_bit when accessing CSR registers.
There is no need to power up the mac to access CSR registers.
Signed-off-by: Abhijeet Kolekar <abhijeet.kolekar@intel.com>
Acked-by: Ben M Cahill <ben.m.cahill@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Unify the usage of apm_stop_master and apm_stop
across all hardwares.
Signed-off-by: Abhijeet Kolekar <abhijeet.kolekar@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The iwlwifi drivers have LED blinking requirements that
mac80211 cannot fulfill due to the use of just a single
LED instead of different ones for TX, RX, radio etc.
Instead, the single LED blinks according to transfers
and is solid on the rest of the time. As such, having
LED class devices registered that mac80211 triggers are
connected to is pointless as we don't use the triggers
anyway.

Remove all the useless code and add hooks into the
driver itself. At the same time, make the LED code
abstracted so the core code that determines blink rate
etc. can be shared between 3945 and agn in iwlcore.

At the same time, the fact that we removed the use of
the mac80211 LED triggers means we can also remove the
IWLWIFI_LEDS Kconfig symbol since the LED support is
now self-contained.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

In order to have an easier way to debug issues, create
trace events (using the ftrace framework) that will
allow us to follow exactly what the driver is doing
with the device.

The text format isn't all that useful, but the binary
format can also be obtained easily via debugfs and
then analysed on the fly or offline with debugging
tools.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Multiple MPDUs can be aggregated, transmitted, and finally acknowledged
together using a single BA frame. Block ACK (BA) contains
bitmap size of 64*16 bits so the maximum frame count is 64.
The default value of aggregation frame count suggested by uCode is 31 to
achieve best performance.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Driver should clear the translate table area after receiving "Alive"
response from uCode. This patch corrects a mistake when doing this.
Signed-off-by: Huaxu Wan <huaxu.wan@linux.intel.com>
Signed-off-by: Guo Chaohong <chaohong.guo@linux.intel.com>
Acked-by: Ben M Cahill  <ben.m.cahill@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

In order to support different type of 1000 series NICs we release to
customers before the production release, iwlwifi driver need to support
all the NICs has EEPROM version greater than 0x15c.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

When uCode detects critical temperature it should send "card state
notification" interrupt to driver and then shut itself down to prevent
overheating. There is a race condition where uCode shuts down before it
can deliver the interrupt to driver.
Additional method provided here for driver to enter CT_KILL state based
on temperature reading.

How it works:
Method 1:
If driver receive "card state notification" interrupt from uCode; it
enters "CT_KILL" state immediately

Method 2:
If the last temperature report by Card reach Critical temperature,
driver will send "statistic notification" request to uCode to verify the
temperature reading, if driver can not get reply from uCode within
300ms, driver will enter CT_KILL state automatically.

Method 3:
If the last temperature report by Card did not reach Critical
temperature, but uCode already shut down due to critical temperature.
All the host commands send to uCode will not get process by uCode;
when command queue reach the limit, driver will check the last reported
temperature reading, if it is within pre-defined margin, enter "CT_KILL"
state immediately. In this case, when uCode ready to exit from "CT_KILL" state,
driver need to restart the adapter in order to reset all the queues and
resume normal operation.

One additional issue being address here, when system is in CT_KILL
state, both tx and rx already stopped, but driver still can send host
command to uCode, it will flood the command queue since card was not
responding; adding STATUS_CT_KILL flag to reject enqueue host commands
to uCode if it is in CT_KILL state, when uCode is ready to come out of
CT_KILL, driver will clear  the STATUS_CT_KILL bit and allow enqueue the host
commands to uCode to recover from CT_KILL state.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The file was accidentally added in commit ef2f8d45 ("wl1251: add
wl1251 prefix to all 1251 files"). This happened when I rebased the
patches from a private tree.
Reported-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Kalle Valo <kalle.valo@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Add timer based auto deep sleep feature in libertas driver which can be
configured using iwconfig command. This is tested on SD8688, SD8686 cards
with firmware versions 10.38.1.p25, 9.70.4.p0 respectively on 32-bit and 64-bit
platforms. Tests have been done for USB/CS cards to make sure that the patch
won't break USB/CS code. We didn't test the if_spi driver.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

After the incorporation of the patch entitled "wext: refactor", some
of the wireless drivers in drivers/staging fail to build because they
need to have CONFIG_WIRELESS_EXT and CONFIG_WEXT_PRIV defined.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Refactor wext to
 * split out iwpriv handling
 * split out iwspy handling
 * split out procfs support
 * allow cfg80211 to have wireless extensions compat code
   w/o CONFIG_WIRELESS_EXT

After this, drivers need to
 - select WIRELESS_EXT	- for wext support
 - select WEXT_PRIV	- for iwpriv support
 - select WEXT_SPY	- for iwspy support

except cfg80211 -- which gets new hooks in wext-core.c
and can then get wext handlers without CONFIG_WIRELESS_EXT.

Wireless extensions procfs support is auto-selected
based on PROC_FS and anything that requires the wext core
(i.e. WIRELESS_EXT or CFG80211_WEXT).
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John 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: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Linux keeps scan results up to 15 seconds. This can be a problem for fast
moving clients: they get back stale data. But if the kernel reports the age
of the BSS items, then user-space can simply weed out old entries by itself.
Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This allows for hw support to be enabled for ar9271.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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

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>

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

Commenting unused functions lpphy_restore_dig_flt_state and
lpphy_disable_rx_gain_override, may be we need these functions in future.

This also fixed following compilation warnings :
  CC [M]  drivers/net/wireless/b43/phy_lp.o
drivers/net/wireless/b43/phy_lp.c:383: warning: ‘lpphy_restore_dig_flt_state’ defined but not used
drivers/net/wireless/b43/phy_lp.c:891: warning: ‘lpphy_disable_rx_gain_override’ defined but not used
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Ever since Johannes' "iwlwifi: improve scan support" iwlwifi
no longer needs any of lib80211's functions or definitions.

This patch updates iwlwifi's Kconfig _selections_ and
removes all left lib80211.h inclusions from the source files.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Acked-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

* Get power table offset from the EEPROM instead of using
  a hardcoded value of -5 if the EEPROM rev is >= 21.
* Add support in the 4k eeprom code for tx power offset
  in case we have a 4k AR9280 implementation.
* Fix tx power accuracy at high powers.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This has to be done if the EEPROM supports FCC Midband
capability.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Reduce PLL Settle time and eliminate redundant PLL calls. Also reduce
the LoadNF timeout from 10 msec to 250usec as the 10 msec timeout was
hit with AR9285 in some cases.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Clearing a local variable is unnecessary.
Get rid of it.
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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

* Move 0xa274 and 0xa27c to the top of tx_gain table.
* Update initvals to fix random failure of noise floor calibration.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

For AR5416 chipsets, clearing RTC_RESET_EN when setting
the chip to SLEEP mode results in high power consumption.
This patch fixes this issue by not clearing it for AR5416.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

If the current channel is between 2412 and 2472 MHz and if the channel is
changing to 2484 MHz, then the registers 0xa1f4, 0xa1f8 and 0xa1fc need to be
programmed to the "japan_2484" values.  Conversely, if the current channel
is 2484 MHz and if the channel is changing to one between 2412 and 2472 MHz, then
the three registers need to be programmed to the "normal" values.

This is needed for compliance with Japanese regulatory requirements.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>