Code and data related to agn bitrates can be
part of the agn module rather than being in
the core module.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

By duplicating a little bit of code between 3945
and agn, we can move a lot of code into an agn
specific station management file and thus reduce
the amount of code in core that is dead to 3945.

before:
   text	   data	    bss	    dec	    hex	filename
 212886	   3872	     96	 216854	  34f16	iwlcore.ko
 620542	  10448	    304	 631294	  9a1fe	iwlagn.ko
 314013	   3264	    196	 317473	  4d821	iwl3945.ko

after:
   text	   data	    bss	    dec	    hex	filename
 202857	   3872	     92	 206821	  327e5	iwlcore.ko
 629102	  10448	    308	 639858	  9c372	iwlagn.ko
 314240	   3264	    196	 317700	  4d904	iwl3945.ko

delta:
 -10029   iwlcore.ko
   8560   iwlagn.ko
    227   iwl3945.ko

so it's a net win even if you have both loaded,
likely because a lot of EXPORT_SYMBOLs go away.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

The core module doesn't need to carry around
the code for chain settings that is used for
HT drivers (agn) only.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

The different drivers need to do different things
after a scan, so create a post_scan hook to allow
them to do this.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

iwl_commit_rxon really should be named
iwlagn_commit_rxon, so rename it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

move paramater definitions to a device paramater structure only
leaving the device name, which antennas are used and what firmware
file to use in the iwl_cfg structure.  this will not completely
remove the redundancies but greatly reduce them for devices that
only vary by name or antennas.  the parameters that are more
likely to change within a given device family are left in iwl_cfg.
also separate bt param structure added to help reduce more.
Signed-off-by: NJay Sternberg <jay.e.sternberg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

iwlwifi driver supports multiple devices. Since some device needs
special configuration we create a new iwl_nic_ops structure which is
configurable per device. Currently there is only one function pointer
inside this structure: additional_nic_config().

The iwl_nic_ops structure is added to the top level in struct iwl_ops,
making it easier to change per device. Duplication of the iwl_lib_ops
structure is no longer needed.

With this new ops the previous function pointer set_calib_version is
no longer needed since it is just a per device nic configuration.

As part of the code restructuring, a bug is addressed. Indication of
calib version to uCode is only needed for 6050 devices, however,
current implementation set calib version for all 6000 devices for
which DC calib is needed. To fix this, create iwl6050_ops for 6050
devices and only populate iwl_nic_ops in this structure.
Signed-off-by: NShanyu Zhao <shanyu.zhao@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Tx command response sent to host by uCode after completed
the transmission attempt. The status parameter indicates
whether the transmission was successful, or else why if failed.

Here we keep the counters to help understand the different failure
cases.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Currently we force scan complete at the end of iwl_scan_cancel_timeout
function. This cause race condition when we can get a new scan request
from mac80211 and complete it by iwl_bg_complete from older scan. Change
code to force scan complete only when really needed: device goes down,
interface is removed or scan timeout occurs.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi W Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Rather than duplicating all the checks and even
in case of errors accepting the scan request
from mac80211, we can push the checks to the
caller and in all error cases reject the scan
request right away (rather than accepting and
then saying it was aborted).
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi W Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We're now ready to start using multiple contexts.
We do this by keeping track of the valid interface
types per context (exclusive [ibss] and normal)
and checking which context is "free" when a new
interface is added.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Sometimes we need to send RXON timing even
when we don't have a virtual interface yet,
so pass the context and allow passing one
without a virtual interface pointer.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

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>

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>

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>

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>

Use .cfg to configure the default bt priority boost value;
the default bt priority boost is 0xf0
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Adding configurable parameter in .cfg for the initial Bluetooth traffic
load; set it to IWL_BT_COEX_TRAFFIC_LOAD_NONE for now, but can be change
for debugging or other reason.
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>

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>

By default, aggregation time limit is 4000 uSec, add the parameter to
.cfg
to allow this parameter can be configure per device base if needed.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

No functional changes, just add additional comments to iwl_cfg structure
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>

We do not need export iwl_bg.*scan.*() functions just for initialize
workqueue in other module. Making that functions static helps with
iwl-scan.c code review a bit.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.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>

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>

For WiFi/BT combo devices, add bluetooth statistics counter
read function to debugfs.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Only WiFi/BT combo devices need to use bluetooth version of statistics
notification; adding the flag in .cfg file to indicate the need for
using different data structure.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

"Flush" request can come from two different sources, it can either from
mac80211, or from device when the operation is needed. Here
adding the support for device issue "flush" request.

When receive tx complete with status is TX_STATUS_FAIL_RFKILL_FLUSH,
issue REPLY_TXFIFO_FLUSH command to uCode to flush out all the tx frames
in queues.

In this condition, since mac80211 has no knowledge of "flush" operation,
driver need to stop all the tx queues and wait for the operation
completed before wake up the queues for frames transmission.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>

Adding flush callback support in the driver. Two type of flush can be
issued by mac80211:
1. drop = true: frame drop is ok, issue REPLY_TXFIFO_FLUSH host command
to uCode to drop all the frames in tx fifo queues; then return the
control back to mac80211
2. drop = false: wait for either all the frames in tx fifo queues been
transmitted, or timeout; then return the control back to mac80211

If the flush request coming from mac80211, mac80211 will make sure there
are no additional frames push down to driver before flush operation is
completed.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.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>

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>