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

Set the default WMM AC parameters for BK/BE/VI/VO parameters:

AC        CWmin         CW max      AIFSN      TXOP Limit    TXOP Limit
                                              (802.11b)      (802.11a/g)
AC_BK      15            1023        7           0               0
AC_BE      15            1023        3           0               0
AC_VI       7              15        2          188             94
                                              (6.016ms)       (3.008ms)
AC_VO       3               7        2          102             47
                                              (3.264ms)       (1.504ms)
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Show current qos AC parameters in sysfs
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add "rate_scale_data" debugfs file to show current bit rate (HT and Legacy),
plus additional information (rssi, noise, tsf, beacon time stamp).
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Instead of hard coded value, use the define in iwl-commands.h for
better code maintenance
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Read rev id in nic_config instead of nic_init.
Nic_config has some checking for rev_id but we actually don't read
the rev_id in there.
Signed-off-by: NAbhijeet Kolekar <abhijeet.kolekar@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Somehow these pre-production cards are showing up in the community.
With this message we hope that it will be clear that the hardware is not
supported.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

iwlagn rate scaling will periodically search other rate scale
tables to switch to the best table regarding performance. In the past
the number of search tables were 3. Every time the rate scale algorithm
goes through these available tables in will stay in current table for
some time before start searching again. Recent driver support more
feature and antenna, so we have more tables to search. This patch make
sure we go through all available tables.
Signed-off-by: NMohamed Abbas <mohamed.abbas@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This removes all the dead code that tries to adjust the power
saving level based on the system AC state (inacceptable policy
in the kernel) or based on overtemp conditions (unused).

Also, pass _all_ policy wrt. enabling PS to mac80211, since
we do not use the power_disabled internally I now use that to
mirror the mac80211 CONF_PS setting. When mac80211 turns off
CONF_PS we follow suit. This means that the user power level
(which can currently only be set from sysfs) is not touched
for mac80211 powersave changes.

This means no "association status" checks are necessary since
mac80211 will not allow power save to be enabled when not
associated.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Acked-by: NMohamed Abbas <mohamed.abbas@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

iwlwifi internally needs to keep track of whether PS
is enabled in the firmware or not. To do this, it keeps
a bit in the status flags, called STATUS_POWER_PMI.

The code to set this bit looks as follows:

static int iwl_set_power(struct iwl_priv *priv, void *cmd)
{
	return iwl_send_cmd_pdu_async(priv, POWER_TABLE_CMD,
				      sizeof(struct iwl_powertable_cmd),
				      cmd, NULL);
}

int iwl_power_update_mode(...)
{
	[...]
	if (final_mode != IWL_POWER_MODE_CAM)
		set_bit(STATUS_POWER_PMI, &priv->status);

	iwl_update_power_cmd(priv, &cmd, final_mode);
	cmd.keep_alive_beacons = 0;

	if (final_mode == IWL_POWER_INDEX_5)
		cmd.flags |= IWL_POWER_FAST_PD;

	ret = iwl_set_power(priv, &cmd);

	if (final_mode == IWL_POWER_MODE_CAM)
		clear_bit(STATUS_POWER_PMI, &priv->status);
	else
		set_bit(STATUS_POWER_PMI, &priv->status);

	if (priv->cfg->ops->lib->update_chain_flags && update_chains)
		priv->cfg->ops->lib->update_chain_flags(priv);
	[...]
}

Now, this bit really needs to track what the _firmware_
thinks, not what the driver thinks. Therefore, there is
a race condition here -- the driver sets the bit before
it knows that the async command sent to the card in the
iwl_set_power function has been processed. As a result,
the call to update_chain_flags() may think that the card
has been woken up (PMI bit cleared) while in reality it
hasn't processed the async POWER_TABLE_CMD yet.

This leads to bugs -- any commands the update_chain_flags
function sends can get stuck and subsequent commands also
fail.

The fix is almost trivial: since there's no reason to send
an async command here (in fact, there almost never should
be since many mac80211 callbacks can sleep) just make the
function wait for the card to process the command and then
return and clear the PMI bit.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Acked-by: NMohamed Abbas <mohamed.abbas@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When the microcode fails for any reason, ask mac80211 to
recover instead of trying ourselves and failing at it.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There really is no need to have a separate struct for a
single variable. The fact that it exists is due to the
code legacy, but we can remove that now. Very simple.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The lower 4 bytes of the chipset revision must contain
a non-zero value. This bug was introduced by
"rt2x00: Simplify rt2x00_check_rev".
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It's not needed outside iwl-core.c
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Acked-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

m68k allmodconfig:
| drivers/net/wireless/wl12xx/main.c: In function 'wl12xx_probe':
| drivers/net/wireless/wl12xx/main.c:1273: error: implicit declaration of function 'set_irq_type'
| make[1]: *** [drivers/net/wireless/wl12xx/main.o] Error 1
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NKalle Valo <kalle.valo@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The AR_SREV_9285_1[12]_OR_LATER macros already contains the
AR_SREV_9285 check.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On x86 this allows us to do the following small savings:
shave off 23 % off of the module's data, and
shave off 6  % off of the module's text.

We save 456 bytes, for those counting.

$ size ath9k.ko
   text    data     bss     dec     hex filename
 250794    3628    1600  256022   3e816 ath9k.ko
$ size ath9k-old.ko
   text    data     bss     dec     hex filename
 239114   15308    1600  256022   3e816 ath9k-old.ko

$ du -b ath9k.ko
4034244 ath9k.ko
$ du -b ath9k-old.ko
4033788 ath9k-old.ko
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently queues are stopped when their length reaches their length limit,
but are restarted only when the size of freed range of packet buffer is
not less than the size of the largest possible packet.

This causes permanent queue stop on radio visibility loss in the middle
of ping series: there is plenty of room in the packet buffer, but it is
never freed more than 3 (size of 'best effort' queue) * 288 (ping packet
plus headers) bytes at once.
Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rt2x00_check_rev() was too specific for rt2500usb and rt73usb,
by adding the mask argument (instead of hardcoding it into
the function itself) we can use the function in rt2800usb as
well.

v2: Fix revision mask for rt2800usb
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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

Fix this build error when CONFIG_PM is not set:
drivers/net/wireless/ath/ar9170/usb.c: In function 'ar9170_usb_probe':
drivers/net/wireless/ath/ar9170/usb.c:692:
	error: 'struct usb_device' has no member named 'reset_resume'
Signed-off-by: NAlexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

/drivers/net/wireless/p54/p54usb.c: In function 'p54u_probe':
/drivers/net/wireless/p54/p54usb.c:923: error: 'struct usb_device' has no member named 'reset_resume'

In the struct usb_device the reset_resume attribute is only available
when CONFIG_PM is defined.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In the near future, the driver core is going to not allow direct access
to the driver_data pointer in struct device.  Instead, the functions
dev_get_drvdata() and dev_set_drvdata() should be used.  These functions
have been around since the beginning, so are backwards compatible with
all older kernel versions.

Cc: John W. Linville <linville@tuxdriver.com>
Cc: linux-wireless@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fixes warnings:
  drivers/net/wireless/wl12xx/main.c:87: warning: int format, different
    type arg (arg 2)
  drivers/net/wireless/wl12xx/main.c: In function `wl12xx_fetch_nvs':
  drivers/net/wireless/wl12xx/main.c:125: warning: int format, different
    type arg (arg 2)
  drivers/net/wireless/wl12xx/wl1251.c: In function 'wl1251_upload_firmware':
  drivers/net/wireless/wl12xx/wl1251.c:94: warning: int format, different
    type arg (arg 2)
  drivers/net/wireless/wl12xx/wl1251.c:141: warning: int format, different
    type arg (arg 2)
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Acked-by: NKalle Valo <kalle.valo@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch replaces test_and_set_bit by set_bit since the bit is not
tested anyway
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch change the "is_fat" checking in rate scale to use
iwl_is_fat_tx_allowed() to match the sta and RX_ON command setting.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Tested-by: NConrad Kostecki <ConiKost@gmx.de>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some issues in PS prevent us from supporting it reliably.

When 4965 goes to sleep it stores some data in host DRAM, reads it back
when device wakes up. In 4965 there is a problem that the data is not
correct when ucode starts using it upon wakeup.

For all iwlagn devices there is a problem where command is sent when PS is
enabled. At the moment there is a locking problem with priv->lock not being
held and thus not requesting nic access correctly.

We disable PS until these issues have been resolved.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NMohamed Abbas <mohamed.abbas@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Patch seperates rx_used and rx_free into two
different atomic contexts. We can now avoid using GFP_ATOMIC
for skb allocation and use GFP_KERNEL.
Signed-off-by: NAbhijeet Kolekar <abhijeet.kolekar@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add LED support on the IBM ThinkPad 11a/b/g Wireless LAN Mini Express
Adapter (AR5BXB6), found on the IBM/Lenovo Thinkpad X60/T60/Z60 series.
Signed-off-by: NParide Legovini <legovini@spiro.fisica.unipd.it>
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Update ath5k to use the ctl settings for tx power based on current
regulatory domain.
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Acked-by: NNick Kossifidis <mickflemm@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

* Add spur filter support for RF5413 and later chips
Signed-off-by: NNick Kossifidis <mickflemm@gmail.com>
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

* Add code to support the various antenna scenarios supported by hw

 * For now hardcode the default scenario (single or dual omnis with
 tx/rx diversity working and tx antenna handled by session -hw keeps
 track on which antenna it got ack from each ap/station and maps each
 ap/station to one of the antennas-).
Signed-off-by: NNick Kossifidis <mickflemm@gmail.com>
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

After some debuging we were hitting the following bugs so far...

 * Due to huge channel list hostapd couldn't get infos from the driver
 and couldn't set the channel. If we manualy set the channel after
 hostapd starts (by setting channel to 0 -auto), beacons are sent
 but they wont show up on scan because they are malformed (they have
 channel = 0 because hostapd doesn't update the channel info -this is
 probably a hostapd bug so i'm CCing Jouni) and they get dropped. Bob
 fixed this by only allowing standard channels to be registered so
 now hostapd works as expected.

 * Docs (and HAL source) say that we must write 0 on timer0 when
 operating on AP mode to start TSF increment but this seems to
 mess with DBA in many cases and beacon queue never gets started.
 We fixed that on the previous patch.

 We have some more things to deal with...

 * For some reason (hw bug or something else) after restarting hostapd
 a few times, beacon inteval seems to change from 100ms to a sec
 (we get one beacon per sec).

 * We need to set sleep timers on STA mode and enable power saving +
 support PCF.

 ...but i think it's time we enable AP support "officialy" so that
 we can get more feedback from users. I ran ath5k with the mentioned
 patches + hostapd 0.6.8 and AP mode worked fine (it had some less
 throughput on my tests than IBSS but it worked).
Signed-off-by: NNick Kossifidis <mickflemm@gmail.com>
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

* Write next beacon timer even on AP mode since without this we get
 no beacons + ath9k does it too.  Docs say that we must write 0 on
 this register on AP mode to start TSF increment, we do both to be
 on the safe side.

 * Fix num_tx_pending function, we never read the register :P that's
 why we got all those "beacon queue 7 didn't stop messages".

 * Put full prioriy on beacon queue, lock all queues with lower
 priority using the arblock and also bypass any arblock by seting
 the arblock ignore flag.

 * For the CAB queue (do we need this thing ?, it seems crap) since
 it's supposed to fire up after each beacon (we don't use it on driver
 part, ath9k/MadWiFi does), don't make it DBA gated but instead make
 it fire after each beacon by using the beacon sent gated flag.

 * Increase bmiss threshold to 10, that's what we used on MadWiFi for
 a long time. Also when we have pending frames on the beacon queue (we
 got a beacon that didn't make it on the air) it's more likely that
 the beacon queue never started, probably due to faulty DBA setting,
 so change that "beacon queue didn't stop" message.

 Tested this with AP mode and IBSS mode and seems to work fine ;-)
Signed-off-by: NNick Kossifidis <mickflemm@gmail.com>
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

* Put remaining EEPROM information on ee struct and remove is_hb63
 function.

 Now we also have rfkill stuff available.
Signed-off-by: NNick Kossifidis <mickflemm@gmail.com>
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

* Read Spur channel information from EEPROM and use default channels
 for RF5413 compatible chips that don't have this info on EEPROM.
Signed-off-by: NNick Kossifidis <mickflemm@gmail.com>
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

* Now that we have regulatory control enable the driver to set
 txpower on hw

 * Also use txpower table offset so that we can match
 power range set by user/driver with indices on power table.

 Tested 2 different cards (a CM9 and an RF5112-based ubnt) and got
 the same output using a remote machine to measure per-packet rssi
 (conected the cards using attenuators). I also switched between
 various tx power levels and i saw an equal power change on the remote
 machine (so txpower changes as expected) and verified that we have
 the same output on each rate.
Signed-off-by: NNick Kossifidis <mickflemm@gmail.com>
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Ralink released a new rt2870 driver, these are the obvious
differences I could find. It doesn't same to make my device
work better, but neither does it seem to regress...
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

wl12xx is a driver for TI wl1251 802.11 chipset designed for embedded
devices, supporting both SDIO and SPI busses. Currently the driver
supports only SPI. Adding support 1253 (the 5 GHz version) should be
relatively easy. More information here:

http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?contentId=4711&navigationId=12494&templateId=6123

(Collapsed original sequence of pre-merge patches into single commit for
initial merge. -- JWL)
Signed-off-by: NKalle Valo <kalle.valo@nokia.com>
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>