Not needed since the driver split.  Move single use routines to
calling location and keep static where possible.
Signed-off-by: NDon Fry <donald.h.fry@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

WiFi throughput drops drastically when BT is turned on, BT and WiFi
are simultaneously transmitting/receiving traffic. This is particularly true
when BT has higher priority over WiFi, and hence the device defers TX frames.
The AP assumes that the channel is bad and reduces the data rate, implying
longer airtime, which exacerbates the problem further, resulting ultimately
in what is popularly called the "death-spiral" phenomenon. The use of PS-poll
in such scenarios guarantees a low but consistent throughput.

Since the death-spiral phenomenon is observed only when the RSSI is low, use
PS-poll only when RSSI is low and disable when high, with a known hysterisis.

This feature specifies the high and low thresholds and implements the
callbacks registered with mac80211, which will be called when threshold events
occur.

iwlwifi: dynamic pspoll: optimize rssi monitor code
Signed-off-by: NMeenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This removes the for priv->trans.ops->...
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Now, there are only two functions to send a host command:
* send_cmd that receives a iwl_host_cmd
* send_cmd_pdu that builds the iwl_host_cmd itself and received flags

The flags CMD_ASYNC / CMD_SYNC / CMD_WANT_SKB are not changed by the API
functions.

Kill the unused flags CMD_SIZE_NORMAL / CMD_NO_SKB on the way.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

All "agn" devices use the same hcmd functions, no need to call indirectly.
remove hcmd_ops
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

P2P interfaces must not use CCK rates, only OFDM
rates are allowed. To set this up, we need to set
up the broadcast station to start with 6M instead
of starting with 1M.

Since the interface type can change, also reset
the broadcast station when RXON changes.

This will affect beacons as well.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

During channge channel, tx power will not send to uCode, the tx power command
should send after scan complete. but should also can send after RXON command.

Stable fix identified by Stanislaw Gruszka <sgruszka@redhat.com>.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Cc: stable@kernel.org [2.6.38+]
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

the code always returns ret regardless, so if(ret) check is unecessary.
Signed-off-by: NGreg Dietsche <Gregory.Dietsche@cuw.edu>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes 802.11n stability and performance regression we have
since 2.6.35. It boost performance on my 5GHz N-only network from about
5MB/s to 8MB/s. Similar percentage boost can be observed on 2.4 GHz.

These are test results of 5x downloading of approximately 700MB iso
image:

vanilla: 5.27 5.22 4.94 4.47 5.31 ; avr 5.0420 std 0.35110
patched: 8.07 7.95 8.06 7.99 7.96 ; avr 8.0060 std 0.055946

This was achieved with NetworkManager configured to do not perform
periodical scans, by configuring constant BSSID. With periodical scans,
after some time, performance downgrade to unpatched driver level, like
in example below:

patched: 7.40 7.61 4.28 4.37 4.80 avr 5.6920 std 1.6683

However patch still make better here, since similar test on unpatched
driver make link disconnects with below messages after some time:

wlan1: authenticate with 00:23:69:35:d1:3f (try 1)
wlan1: authenticate with 00:23:69:35:d1:3f (try 2)
wlan1: authenticate with 00:23:69:35:d1:3f (try 3)
wlan1: authentication with 00:23:69:35:d1:3f timed out

On 2.6.35 kernel patch helps against connection hangs with messages:

iwlagn 0000:20:00.0: queue 10 stuck 3 time. Fw reload.
iwlagn 0000:20:00.0: On demand firmware reload
iwlagn 0000:20:00.0: Stopping AGG while state not ON or starting

Cc: stable@kernel.org # 2.6.35+
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>

Both tx power and power save are being done after scan complete, move into
post_scan function
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

For some timing reason, 1000 device having problem to kick-in to aggregation
without sending rxon assoc command. This is a W/A until find the real reason
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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

These bugs were introduced by:

commit 79d07325
Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date:   Thu May 6 08:54:11 2010 -0700

    iwlwifi: support channel switch offload in driver

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

Also remove iwl2030_hw_channel_switch() since 2000 series adapters are
2.4GHz only devices.

Cc: stable@kernel.org # 2.6.36+
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>

 The PAN context has three states: disabled, disassociated
 and associated. It seems that wasn't quite as much of an
 issue in previous versions of the microcode, but now we
 really have to use all the three states properly. So add
 code to switch accordingly.

Additionally, PAN parameters need to be sent differently
and the timing for PAN RXON needs to be inbetween.
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>

During channge channel, tx power will not send to uCode, the tx power command
should send after scan complete. but should also can send after RXON command.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

old_assoc not used, remove it
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Before send the RXON command with associated flag set, always do disassociate
first to make sure uCode is in the correct state.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

All agn devices use the same module parameter structure.  Delete the
indirection and access the structure diretly.
Signed-off-by: NDon Fry <donald.h.fry@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

No functional changes, separate the connect and disconnect sequences in
RXON commit function, easier to read and understand.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

The data structure is shared by all _agn devices, remove the reference to 5000
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Move rxon_assoc to static function from ops
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

We're unlikely to care about the actual time spent
waiting, so make the function return an error code
which is less error prone in coding new uses.

Also, while at it, mark __must_check.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

A notification wait function is called with the
command, but currently has no way of passing
data back to the caller -- fix that by adding a
void pointer to the function that can be used
between the caller and the function.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

For some reason, sending QoS configuration causes transmission to stop
after a single frame on HT channels when not associated. Removing the
extra QoS configuration has no effect on station mode, and fixes
injection mode.
Signed-off-by: NDaniel Halperin <dhalperi@cs.washington.edu>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

The microcode may sometimes reject TX frames when
on a radar channel even after we associated as it
clears information during association and needs to
receive a new beacon before allowing that channel
again. This manifests itself as a TX status value
of TX_STATUS_FAIL_PASSIVE_NO_RX. So in this case,
stop the corresponding queue and give the frame
back to mac80211 for retransmission. We start the
queue again when a beacon from the AP is received
which will make the regulatory enforcement in the
device allow transmitting again.
Signed-off-by: NGaren Tamrazian <garenx.tamrazian@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This function was intended to calculate the
number of RX chains needed, but could only
work where the AP's streams were asymmetric,
i.e. 2 TX and 3 RX or similar. In the case
where IEEE80211_HT_MCS_TX_RX_DIFF was not
set, this function would calculate the wrong
information.

Additionally, mac80211 didn't pass through
the required values at all, so it couldn't
work anyway.

Rewrite the logic in this function and add
appropriate comments to make it readable.
Signed-off-by: NJohannes Berg <johannes.berg@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>

For device supporting PAN/P2P, use the PAN
context to implement the remain-on-channel
operation using device offloads so that the
filters in the device will be programmed
correctly -- otherwise we cannot receive
any probe request frames during off-channel
periods.
Signed-off-by: NJohannes Berg <johannes.berg@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>

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>

Previously I hacked this with an msleep(300)
which was fine since we never had longer PAN
time slots, but now that we will have them I
need to fix that. Use the new notification
wait support to properly wait for the WIPAN
deactivation complete signal from the ucode.
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>

patch "iwlagn: check ready in iwlagn_bss_info_changed()" introduce
whitespace, fix it

please merge with the previous patch

Reported by: Johannes 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 function iwlagn_bss_info_changed(), we need to check if the driver
is ready before doing real work. Also, the previously put WARN() is
removed because the vif is not guaranteed to be valid. uCode restart
routine will clear the vif.
Signed-off-by: NShanyu Zhao <shanyu.zhao@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

If driver is on the way down, there is no need to send
RXON to uCode, check the condition before continuous the process.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

RXON command without association bit can clear the QoS info in the
uCode. Therefore, before sending the associated RXON, we need to
send the QoS command just in case.
Signed-off-by: NShanyu Zhao <shanyu.zhao@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Instead of unconditionally sending unassoc RXON,
before any assoc RXON, re-send only the AP STA
entry which is required after the BSSID has been
programmed into the device to set up internal
filters in the microcode properly.

This fixes some issues that we correlated with
sending a lot of RXON commands to the device.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

For reasons that aren't entirely clear to me,
we sometimes get here during hardware reset
without the interface being set. Don't crash,
but keep a warning.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

When the HT information is changed due to
BSS changes (like legacy stations joining)
we need to recalculate HT RXON parameters.
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>

During the RXON rewrite, this code got lost.
When we've just associated, we need to enable
all calibrations and see if some were already
finished. Add back the missing code.
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>

The RXON rework resulted in a massive loss of
throughput because we weren't programming the
device completely correctly -- the BSSID has
to be programmed into the device before the
AP station is uploaded. To fix this, simply
always send the unassoc RXON, i.e. even when
it was already unassoc so that the BSSID and
some other parameters are updated properly.
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>