tx params should be configured per interface.
add ieee80211_vif param to the conf_tx callback,
and change all the drivers that use this callback.

The following spatch was used:
@rule1@
struct ieee80211_ops ops;
identifier conf_tx_op;
@@
	ops.conf_tx = conf_tx_op;

@rule2@
identifier rule1.conf_tx_op;
identifier hw, queue, params;
@@
	conf_tx_op (
-		struct ieee80211_hw *hw,
+		struct ieee80211_hw *hw, struct ieee80211_vif *vif,
		u16 queue,
		const struct ieee80211_tx_queue_params *params) {...}
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

TSF can be kept per vif.
Add ieee80211_vif param to set/get/reset_tsf, and move
the debugfs entries to the per-vif directory.

Update all the drivers that implement these callbacks.
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

iwlegacy version of fix:

commit effd4d9a
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Sep 15 11:46:52 2011 -0700

    iwlagn: do not use interruptible waits

    Since the dawn of its time, iwlwifi has used
    interruptible waits to wait for synchronous
    commands and firmware loading.

    This leads to "interesting" bugs, because it
    can't actually handle the interruptions; for
    example when a command sending is interrupted
    it will assume the command completed fully,
    and then leave it pending, which leads to all
    kinds of trouble when the command finishes
    later.

    Since there's no easy way to gracefully deal
    with interruptions, fix the driver to not use
    interruptible waits.

    This at least fixes the error
    iwlagn 0000:02:00.0: Error: Response NULL in  'REPLY_SCAN_ABORT_CMD'

    I have seen in P2P testing, but it is likely
    that there are other errors caused by this.

Cc: stable@kernel.org # 2.6.39+
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Messages like that

iwl4965 0000:03:00.0: Start IWL Event Log Dump: display last 20 entries
iwl4965 0000:03:00.0: EVT_LOGT:1821445332:0x00000000:1352
iwl4965 0000:03:00.0: EVT_LOGT:1821445332:0x00000001:1353
iwl4965 0000:03:00.0: EVT_LOGT:1821445336:0x0000000c:0357
iwl4965 0000:03:00.0: EVT_LOGT:1821445533:0x00000107:0106
iwl4965 0000:03:00.0: EVT_LOGT:1821445534:0x00000000:0302
iwl4965 0000:03:00.0: EVT_LOGT:1821445574:0x000000d4:0321
iwl4965 0000:03:00.0: EVT_LOGT:1821445575:0x00000000:1350
iwl4965 0000:03:00.0: EVT_LOGT:1821445576:0x00000000:1351
iwl4965 0000:03:00.0: EVT_LOGT:1821445576:0x00000000:1352
iwl4965 0000:03:00.0: EVT_LOGT:1821445577:0x00000001:1353
iwl4965 0000:03:00.0: EVT_LOGT:1821445581:0x0000000d:0357
iwl4965 0000:03:00.0: EVT_LOGT:1821446327:0x00000107:0106
iwl4965 0000:03:00.0: EVT_LOGT:1821446328:0x00000000:0302
iwl4965 0000:03:00.0: EVT_LOGT:1821446368:0x000000d4:0321
iwl4965 0000:03:00.0: EVT_LOGT:1821446369:0x00000000:1350
iwl4965 0000:03:00.0: EVT_LOGT:1821446370:0x00000000:1351
iwl4965 0000:03:00.0: EVT_LOGT:1821446370:0x00000000:1352
iwl4965 0000:03:00.0: EVT_LOGT:1821446371:0x00000001:1353
iwl4965 0000:03:00.0: EVT_LOGT:1821446375:0x0000000e:0357
iwl4965 0000:03:00.0: EVT_LOGT:1821446383:0x00000000:0125

are completely useless for me. Remove bunch of code that generate them.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We do not reset radio anymore, hence don't need that code too.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We use priv->mutex to avoid race conditions between chswitch_done()
and mac_channel_switch(), when marking channel switch in
progress. But chswitch_done() can be called in atomic context
from rx_csa() or with mutex already taken from commit_rxon().

To fix remove mutex from chswitch_done() and use atomic bitops
for marking channel switch pending.

Cc: stable@kernel.org # 2.6.39+
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We should not switch to non-IBSS channels when working in IBSS mode,
otherwise there are microcode errors, and after some time system
crashes.

This bug is only observable when software scan is used in IBSS mode,
so should be considered as regression after:

commit 0263aa45
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Tue Mar 29 11:24:21 2011 +0200

    iwl3945: disable hw scan by default

However IBSS mode check, which this patch add again, was removed by

commit b2f30e8b
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Jan 21 07:32:20 2010 -0800

    iwlwifi: remove IBSS channel sanity check

That commit claim that mac80211 will not use non-IBSS channel in IBSS
mode, what definitely is not true. Bug probably should be fixed in
mac80211, but that will require more work, so better to apply that patch
temporally, and provide proper mac80211 fix latter.

Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=34452Reported-and-tested-by: NMikko Rapeli <mikko.rapeli@iki.fi>
Cc: stable@kernel.org # 2.6.38.5+
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Check status bits with mutex taken, because when we wait for mutex
unlock, status can change. Patch should also make remaining sync
commands be send with priv->mutex taken. That will prevent execute
these commands when we are currently reset firmware, what could
possibly cause troubles.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We never set STATUS_SCANNING in softwre scanning mode, disable_hw_scan
check is unneeded. Correct debug message while at it.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Don't need to use conditional as ch->band is already assigned to
IEEE80211_BAND_5GHZ or IEEE80211_BAND_2GHZ
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

priv->tx_power_next is not initialized to max supported power,
but instead default value is used, what cause errors like

[   58.597834] iwl3945 0000:03:00.0: Requested user TXPOWER 15 above upper limit 14.
[   58.597839] iwl3945 0000:03:00.0: Error setting Tx power (-22).

if maximum tx power read from the eeprom is smaller than default.
In consequence card is unable to initialize properly. Fix the problem
and cleanup tx power initialization.
Reported-and-tested-by: NRobin Dong <hao.bigrat@gmail.com>
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>

If change_interface gets invoked during a firmware
restart, it may crash; prevent that from happening
by checking if ctx->vif is assigned.

Additionally, in my initial commit I forgot to set
the vif->p2p variable correctly, so fix that too.

Cc: stable@kernel.org [2.6.38+]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

drivers/net/wireless/iwlegacy/built-in.o:(.rodata+0x29f0): multiple definition of `iwl_rates'
drivers/net/wireless/iwlwifi/built-in.o:(.rodata+0xa68): first defined here
powerpc64-linux-ld: Warning: size of symbol `iwl_rates' changed from 143 in drivers/net/wireless/iwlwifi/built-in.o to 130 in drivers/net/wireless/iwlegacy/built-in.o
drivers/net/wireless/iwlegacy/built-in.o:(.data+0x0): multiple definition of `bt_coex_active'
drivers/net/wireless/iwlwifi/built-in.o:(.data+0x668): first defined here
drivers/net/wireless/iwlegacy/built-in.o:(.rodata+0x750): multiple definition of `iwl_eeprom_band_1'
drivers/net/wireless/iwlwifi/built-in.o:(.rodata+0x27d0): first defined here
drivers/net/wireless/iwlegacy/built-in.o:(.rodata+0x3f0): multiple definition of `iwl_bcast_addr'
drivers/net/wireless/iwlwifi/built-in.o:(.rodata+0x24f8): first defined here
drivers/net/wireless/iwlegacy/built-in.o:(.bss+0x3d48): multiple definition of `iwl_debug_level'
drivers/net/wireless/iwlwifi/built-in.o:(.bss+0x21950): first defined here
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Same fix as f844a709
"iwlwifi: do not set tx power when channel is changing".
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Intel WiFi devices 3945 and 4965 now have their own driver in the folder

	drivers/net/wireless/iwlegacy

Add support to build these drivers independently of the driver for
AGN devices. Selecting the 3945 builds iwl3945.ko and iwl_legacy.ko,
and selecting the 4965 builds iwl4965.ko and iwl_legacy.ko. iwl-legacy.ko
contains code shared between both devices.

The 3945 is an ABG/BG device, with no support for 802.11n. The 4965 is a 2x3
ABGN device.
Signed-off-by: NMeenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Acked-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

This reverts commit aa833c4b.

Intel WiFi devices 3945 and 4965 now have their own driver in the folder

	drivers/net/wireless/iwlegacy

Add support to build these drivers independently of the driver for
AGN devices. Selecting the 3945 builds iwl3945.ko and iwl_legacy.ko,
and selecting the 4965 builds iwl4965.ko and iwl_legacy.ko. iwl-legacy.ko
contains code shared between both devices.

The 3945 is an ABG/BG device, with no support for 802.11n. The 4965 is a 2x3
ABGN device.
Signed-off-by: NMeenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Acked-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

If device has serious problem and cause firmware can not recover itself.
Keep reloading firmware will not help, it can only fill up the syslog and
lock up the system because busy reloading.

Introduce the limit reload counter, if the reload reach the maximum within
the pre-defined duration;stop the reload operation.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

After commit 59eb21a6
"cfg80211: Extend channel to frequency mapping for 802.11j"
we use uninitialized sband->band when assign channel frequencies, what
results that 5GHz channels have erroneous (zero) center_freq value.

Patch fixes problem and simplifies code a bit.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Mac80211 can request for tx power and channel change in one ->config
call. If that happens, *_send_tx_power functions will try to setup tx
power for old channel, what can be not correct because we already change
the band. I.e  error  "Failed to get channel info for channel 140 [0]",
can be printed frequently when operating in software scanning mode.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If PAN functionality is present, advertise
P2P interface type support and thus support
for P2P. However, the support is currently
somewhat incomplete -- NoA schedule isn't
added to probe responses, and 11b bitrates
may be used still, etc. Therefore, make it
all optional with a Kconfig option.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Instead of keeping track of LED blink speed
in the driver, use the new mac80211 trigger
and link it up with an LED classdev that we
now register. This also allows users more
flexibility in how they want to have the LED
blink or not.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Extend channel to frequency mapping for 802.11j Japan 4.9GHz band, according to
IEEE802.11 section 17.3.8.3.2 and Annex J. Because there are now overlapping
channel numbers in the 2GHz and 5GHz band we can't map from channel to
frequency without knowing the band. This is no problem as in most contexts we
know the band. In places where we don't know the band (and WEXT compatibility)
we assume the 2GHz band for channels below 14.

This patch does not implement all channel to frequency mappings defined in
802.11, it's just an extension for 802.11j 20MHz channels. 5MHz and 10MHz
channels as well as 802.11y channels have been omitted.

The following drivers have been updated to reflect the API changes:
iwl-3945, iwl-agn, iwmc3200wifi, libertas, mwl8k, rt2x00, wl1251, wl12xx.
The drivers have been compile-tested only.
Signed-off-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NBrian Prodoehl <bprodoehl@gmail.com>
Acked-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The below patch fixes a typo "diable" to "disable". Please let me know if this
is correct or not.
Signed-off-by: NJustin P. Mattock <justinmattock@gmail.com>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

For debugging purpose, keep track of the bt coex enable/disable state.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

For WiFi/WiMAX combo devices, if WiMAX own the RF, WiFi driver
try to access RF and fail. This is the W/A to To avoid WiFi keep
reloading firmware and try to access RF again.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

This patch replace monitor/recover timer by watchdog based on time
stamp. New code allow to discover hangs more precisely.

Timeout values are currently doubled monitoring period values of
previous timer. This have to be tuned based of firmware timing
capabilities.

Tested on 3945, 4965, 5300, 6300.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use dynamic aggregation threshold if bt traffic load is high
to reduce the impact on aggregated frame.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Legacy (4965 and 3945) devices has different tx_cmd_protection routine.
Move to iwl-legacy.c
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Move iwl_isr_legacy function to iwl_legacy.c since it only used
by legacy devices.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Implement switching the interface while an
interface is up in iwlwifi. Interfaces have
to stay on the context they were created on.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In order to simplify the flow, and make new
enhancements easier, separate out the RXON
processing for modern AGN (5000 and newer)
from RXON processing for the older 3945 and
4965 devices. Avoid changing these old ones
to avoid regressions and move their code to
a new file (iwl-legacy.c). 4965 gets the
commit_rxon that used to be common for all
AGN devices, but with removed PAN support.

The new RXON processing is more central and
does more work in committing, so that it is
easier to follow.

To make it more evident what is split out
for legacy, split the necessary operations
for that into a new struct iwl_legacy_ops.
Those parts that still exist in the new AGN
code don't need to be parametrized.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In the future, 4965 and modern AGN devices will
need to have different mac80211 callbacks since
they have different capabilities. Prepare for
that by making the mac80211 operations a device
config.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use the new PCI PM and let the PCI core code handle the PCI-specific
details of power transitions.

Based on similarly titled ath9k patch posted by Rafael J. Wysocki.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Currently we are canceling scan when changing BSSID. Behave the same
when changing association and beacon enablement, to avoid committing
rxon during scan in iwl_set_no_assoc().
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

According to comment in iwl_bg_scan_completed, setting tx power should
be deferred during pending scan, but we are not doing this.

This patch change code to really defer setting tx power after scan
complete. Additionally refactor iwl_set_tx_power code and call
lib->send_tx_power() directly from iwlagn_commit_rxon.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We recently found that contrary to expectations,
the LED is not blinking in IBSS mode. Fix this.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

The RXON checking is a bit magical, and prints
out too much information if something goes wrong.
Make it less magical and print out only the items
that were actually wrong.

Also remove the comment about removing it -- the
driver is constantly changing so these checks are
useful.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>