The function has an unsigned return type, but returns a negative constant
to indicate an error condition.  Another error condition in the same
function is indicated by returning 0, and indeed the only call to the
function checks for 0 to detect errors, so the return of a negative value
it converted to a return of 0.

A sematic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@exists@
identifier f;
constant C;
@@

 unsigned f(...)
 { <+...
*  return -C;
 ...+> }
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In uCode, BT state machine need to receive open envlope
command before perform calibration; followed by close envlope
command to move to next stage.

Since Linux has two separated uCode, one for init and the second
one for runtime; we use open envlope commands for init uCode to
indicate we are ready to perform calibration operation.
But for runtime uCode, we are not doing any init calibration,
so we issue open/close envlope commands to force uCode move to
"BT COEX ON" state.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.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>

The PAN context requires also getting
RXON timing when we send an unassociated
RXON in some cases.
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>

Newer AGN microcode requires know the beacon
before starting the AP so that it can start
beaconing right away. Implement that.
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>

Frames for different contexts need to be put
on different queues, and multicast after DTIM
frames have a special queue yet which also
depends on the context, so put all this into
the context.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Since we have the beacon context now, we no
longer need to rely on iw_mode but can check
the beacon context interface's type. However,
that check must be in the work item instead
due to locking constraints (mutex must be
held when dereferencing beacon_ctx pointer).
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Detect whether or not the ucode is PAN
capable and adjust the valid contexts
accordingly. To be able to do this, add
the PAN context to the array as well.
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>

Sometimes we only pass around station
pointers but need to find the context
they belong to, so store it in there.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

HW crypto needs to be aware of the context, and there
are different command IDs for the WEP keys per context,
so move the key tracking variables and command IDs 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>

Each context needs to use a different AP sta
ID, so we need to move that into the context
struct instead of hardcoding it.
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 microcode tracks stations per context, so
the driver needs to do that as well for adding,
deleting and restoring them, especially in the
implicit removal case when we send an RXON.
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 capable microcode has a different
queue assignment (not just more queues
for PAN) due to the way multicast is
handled for AP mode.
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>

Move bt coex functions to iwl-agn-lib.c, so those functions
can be shared by multiple wifi/bt combo devices
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.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>

Add bt_ch_announce module parameter to enable/disable BT channel
announcement mode; default is "enable"

Based on the bt channel announcement module parameter to configure the
bt_config host command.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add additional bt coex related parameters and initialize at init
time.
Thoese parameters will be used in later implementations.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

1. Based on uart message from uCode, re-configure BT kill ack mask
messages from uCode
2. send REPLY_BT_COEX_SCO command to uCode based on the uart frame
received from uCode
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>

bt config command need to send before the init calibration command,
driver need to let uCode know that calibrations are being performed now
in order to assure antenna is not being taken to BT use during radio/dsp
reads/writes

Also, bt_coex_priorty_table command need to be send right after the
bt_config_command during init sequence. Followed by bt coex envelope
command to initialize and prepare uCode bt state machine
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>

The BT SCO needs to be re-applied to the device,
while the traffic load just needs to be correct
in software.
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>

When we turn off the device, reset BT
data so that we don't have outdated
information when we come up again.
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>

To make del_timer_sync() works we have to assure that timer function
does not rearm the timer. To achieve that we cancel timer with
STATUS_EXIT_PENDING bit set in __iwl{3945,}_down function.

Patch also fix priv->txq memory usage after free for iwl3945, because
it move timer cancellation before iwl3945_hw_txq_ctx_free(priv) is called.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Even when we configure WEP keys in AP mode
ones without a station pointer are default
keys, so don't check for AP mode here.
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>

ucode firmware may need to be released as experimental for testing or
debugging. released ucode filenames have the API version as the last
component.  experimental ucode files will have that component be "exp"
and the fw_version string reported by ethtool will also contain the
string EXP to clearly identify this ucode from released ucode.
EXP is short for EXPERIMENTAL since fw_version has a max lenght on 32.

this capability is controlled by Kconfig and defaulted to not be used.
Signed-off-by: NJay Sternberg <jay.e.sternberg@intel.com>
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>

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>