In order for the microcode to be able to handle
multiple interfaces, we need to give it the PAN
parameters that state how to allocate the time
between the two interfaces. Do this, and update
it wherever necessary.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

The PAN functionality requires us to send the
timing including a valid DTIM period to the
microcode before associating, so request this
data from mac80211 and send it to the device.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Only one context can be beaconing at a time,
but we need to track which one. Introduce a
new variable priv->beacon_ctx to do that.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

A lot of HT configuration semantically belongs into
the context, even if right now it will never be
different between contexts. Move it so we're better
prepared for future changes in mac80211.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

iwlwifi occasionally needs to find the virtual
interface pointer to give it to mac80211, but right
now it only keeps one. Move it into the context so
that we can keep one pointer each.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Since mac80211 doesn't currently enable/disable
QoS per interface, we can't yet do it properly,
but we can already prepare for it and move the
QoS data and command ID into the context struct.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Some commands will have different command IDs
for different contexts, so we need to store
those IDs in the context structure and use
them instead of hardcoding the commands.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

The broadcast station ID is per context, so
add a variable for the ID in the context and
use it everywhere we previously hardcoded it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

PAN ucode will require a different queue assignment,
in particular queue 9 instead of 4 should be used for
commands.

This is required because the ucode will stop/start
queues 4 and 8 depending on the PAN state, since
queue 8 will be used for PAN multicast (after DTIM).
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

In order to support multiple interfaces, we must move
a lot of data into per-context structures so we can
use the contexts the device offers. To start with,
this makes a lot of code context-aware, more changes
will move more things into the context structure.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Current BT traffic load should based on the following conditions:

1. BT On/Off status
2. Channel announcement enable/disable
3. Curren traffic load report from uCode

Need to modify rate scale to down-grade from MIMO to SISO if detected
high BT traffic load. Also need to make sure not using chain "B" with high
BT traffic or if it is in "full concurrency" mode.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In current implementation, stuck queue timer is fixed to 1 second. Add
debugfs file to modify the timer to enhance the flexibility:

Set the monitor_period as following:
   0: disable stuck queue force reset function
   1 - 60000: monitor period (1 - 60 second)
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Adding the bluetooth full concurrency support for WiFi/BT combo devices.

Driver should configure uCode to operate in "full concurrency" mode (via
LUT) if both conditions are met:
 - Antenna Coupling is more than 35dB
 - WiFi Channel Inhibition Request is hornored by BT Core

Currently, there is no antenna coupling information provided by uCode;
use module parameter to specified the antenna coupling in dB.

When in "full concurrency" mode, driver need to download different LUT
to uCode while sending bt configuration command; also, driver need to
configure the device operate in 1x1 while in full concurrency mode.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When bluetooth indicated high load, we should use
only antenna A in 2.4 GHz for management frames.
Add this condition to iwl_toggle_tx_ant() to make
sure it'll always be met. Note that scanning has
a separate way of forcing the antenna, because we
should scan on antenna A only regardless of BT
traffic load.
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>

Disable plcp error checking for 6000g2b devices, with wifi/bt coex;
this got trigger too often, disable for now until finding better
trigger point.

Also extend the firmware reload timer much longer for BT coex to make sure
there are will be no mistake to reload firmware too fast and too often.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

IBSS doesn't allow for coexistence, so it
should be disabled.

Additionally, disable reacting to the BT
profile notification when in IBSS mode,
it likely won't be sent by the device to
start with though.

Also, in IBSS mode, BT coexistence isn't as fully-featured
and we must use a single antenna only. So instead of
peppering the code with new checks, simply pretend
we are in high BT traffic load, which has the needed
effect of disabling antenna B use.
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>

6000g2b hardware implements advance bluetooth coexist command,
implement base on the new API command strucutre.

Also increment the API 5 to support the advance BT/WIfi coex.
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>

iwl_send_card_state() is not being call from anywhere, remove it.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Add ampdu factor and density to .cfg, this allow both parameters
can be configure per device based.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

All callers of iwl_setup_rxon_timing() also send
the command right away, so rename the function
to iwl_send_rxon_timing() and move the sending
into it. Also, some callers clear the data, this
can be done always and thus moved in as well.
Finally, there's no reason for the function to
acquire the spinlock, but it should be called
with the mutex held, so assert that.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Update outdated comments of iwl_set_rxon_channel() to reflect the
current signature. Also remove the unnecessary validation of the
channel. Those channel info are constructed in iwlwifi driver
and mac80211 will never modify the content of the struct. Also
everytime before this function is called the channel info has
been validated already (as a paranoid check).
Signed-off-by: NShanyu Zhao <shanyu.zhao@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

When iwl_mac_config() is called by mac80211, the channel pointer
hw->conf->channel can potentially change, resulting in mismatch
band and channel number when configuring RXON command. To avoid
this situation, save the channel pointer in local variables
and validate the channel before using it. Note that priv->mutex
is locked during the whole function so the local variables are safe.

Same change is applied to iwl_mac_channel_switch() since basically
it copies code from iwl_mac_config().

Also removed an outdated comment in the flow.
Signed-off-by: NShanyu Zhao <shanyu.zhao@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

A few cases in iwlwifi driver function ieee80211_frequency_to_channel()
is called to get channel number from center frequency. This is not needed
since the channel number is already saved in hw_value field of struct
ieee80211_channel in function iwlcore_init_geos(). So replace those function
calls with hw_value field of struct ieee80211_channel.
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>

"Thermal Throttling" is an advance feature which only available for
newer _agn devices. Move from iwl-core to iwl-agn for better code
organization.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Applying the filter flags directly as done since

commit 3474ad63
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Apr 29 04:43:05 2010 -0700

    iwlwifi: apply filter flags directly

broke 3945 under some unknown circumstances, as
reported by Alex.

Since I want to keep the direct application of
filter flags on iwlagn, duplicate the code into
both 3945 and agn and remove committing the
RXON that broke things from the 3945 version.

Cc: stable@kernel.org [2.6.35]
Reported-by: NAlex Romosan <romosan@sycorax.lbl.gov>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Only the IBSS manager, ie. the station that sent
the IBSS beacon last, should be replying to probe
responses. This requires implementing the mac80211
tx_last_beacon callback, which we can do thanks to
the ucode beacon notification.
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>

iwl_set_hw_params() only used by _agn, make it static
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

iwl_hw_detect() only used by _agn, make it static
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently the driver will try to protect all frames,
which leads to a lot of odd things like sending an
RTS with a zeroed RA before multicast frames, which
is clearly bogus.

In order to fix all of this, we need to take a step
back and see what we need to achieve:
 * we need RTS/CTS protection if requested by
   the AP for the BSS, mac80211 tells us this
 * in that case, CTS-to-self should only be
   enabled when mac80211 tells us
 * additionally, as a hardware workaround, on
   some devices we have to protect aggregated
   frames with RTS

To achieve the first two items, set up the RXON
accordingly and set the protection required flag
in the transmit command when mac80211 requests
protection for the frame.

To achieve the last item, set the rate-control
RTS-requested flag for all stations that we have
aggregation sessions with, and set the protection
required flag when sending aggregated frames (on
those devices where this is required).

Since otherwise bugs can occur, do not allow the
user to override the RTS-for-aggregation setting
from sysfs any more.

Finally, also clean up the way all these flags get
set in the driver and move everything into the
device-specific functions.

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

commit f84b29ec
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue May 18 02:29:13 2010 -0700

    iwlwifi: queue user-initiated scan when doing internal scan

introduced a potential deadlock because it calls
ieee80211_scan_completed() with the priv->mutex
held, but mac80211 may call back into iwlwifi
which would lead to recursive locking. Move this
out from under the mutex.

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

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

This function is only needed in the same
file it is defined in, i.e. iwl-core.c
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Ever since

commit e1b3ec1a
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Mon Mar 29 12:18:34 2010 +0200

    mac80211: explicitly disable/enable QoS

mac80211 is telling drivers, in particular
iwlwifi, whether QoS is enabled or not.

However, this is only relevant for station mode,
since only then will any device send nullfunc
frames and need to know whether they should be
QoS frames or not. In other modes, there are
(currently) no frames the device is supposed to
send.

When you now consider virtual interfaces, it
becomes apparent that the current mechanism is
inadequate since it enables/disables QoS on a
global scale, where for nullfunc frames it has
to be on a per-interface scale.

Due to the above considerations, we can change
the way mac80211 advertises the QoS state to
drivers to only ever advertise it as "off" in
station mode, and make it a per-BSS setting.
Tested-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

fw_restart module parameter was broken by the recent check for stuck
queue patch, driver check the fx_restart module parameter
before reload the firmware; but the stuck queue timer kick in after
firmware error and reload the firmware even fw_restart=0. In this case,
driver should not reload the firmware, it is important to help debugging
uCode error.

The only case we can ignore the module parameter is when user request
firmware reload from debugfs, which can bypass the checking and perform
firmware reload all the time.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

When resuming from hibernate or suspend,
the status of the rfkill switch isn't
known since it might have been toggled
while the system was asleep. Therefore,
we need to read out the status at resume
time to make sure the system knows about
an up-to-date status.
Reported-by: NMark Tung <mark.y.tung@intel.com>
Tested-by: NMark Tung <mark.y.tung@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

The rate table in the bcast LQ is computed only when the station is
allocated, and chooses the lowest rate for the band. Because of when this
occurs, this is the 2.4 GHz band and uses the 0x420a (CCK, 1 Mbps) rate. In 5 GHz
beaconing mode, this rate will prevent beacons from being sent and any other
packets from being received.

We can fix this by re-initializing the bcast station's LQ command when the
channel is changed.
Signed-off-by: NDaniel Halperin <dhalperi@cs.washington.edu>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

commit 3474ad63
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Apr 29 04:43:05 2010 -0700

    iwlwifi: apply filter flags directly

broke multicast. The reason, it turns out, is that
the code previously checked if ALLMULTI _changed_,
which the new code no longer did, and normally it
_never_ changes. Had somebody changed it manually,
the code prior to my patch there would have been
broken already.

The reason is that we always, unconditionally, ask
the device to pass up all multicast frames, but the
new code made it depend on ALLMULTI which broke it
since now we'd pass up multicast frames depending
on the default filter in the device, which isn't
necessarily what we want (since we don't program it
right now).

Fix this by simply not checking allmulti as we have
allmulti behaviour enabled already anyway.
Reported-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Tested-by: NMaxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The internal scanning created a problem where
when userspace tries to scan, the scan gets
rejected. Instead of doing that, queue up the
user-initiated scan when doing an internal
scan.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

In "iwlwifi: make scan antenna forcing more generic"
I introduced generic scan RX antenna forcing, which
here I rename to make it more evident. Also add scan
TX antenna forcing, since I will need that as well.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

This variable is now no longer used, so it
can be removed completely.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>