New microcode versions use the good CRC threshold
field differently, as a flag, and in that case we
should set it to 1/0 instead of 1/65535 for an
active/passive scan.

The new behaviour is advertised by the uCode with
a feature flag.
Signed-off-by: NJohannes Berg <johannes.berg@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>

The WoWLAN resume code will have to essentially
do a restart, but without going through the work
struct. To support that, refactor the restart by
splitting out the preparation code into a new
function.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

There are a few cases like the WoWLAN support
I'm writing that require attempting to access
the NIC when it is known that it might not be
accessible, e.g. after the system woke up and
the platform might have reset the device.

To avoid messages in this case, introduce the
new function iwl_grab_nic_access_silent(), it
will only return an error status.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

If a device error happens while the uCode is
being loaded or initialised, we will attempt
to restart the device (which will likely fail
again, but that's not the issue here). During
this new restart, we turn off the device, but
as the uCode failed to initialise it already
is turned off. As a consequence, grabbing NIC
access will fail and cause excessive messages
and hangs.

To fix this issue, introduce a new status bit
and only attempt to reprogram the device when
it isn't already disabled.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Since

commit f844a709
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Fri Jan 28 16:47:44 2011 +0100

    iwlwifi: do not set tx power when channel is changing

we set device tx power during initialization to priv->tx_power_next,
which itself is initialized to minimum power. That changed
default behaviour of driver. Previously we initialized device to
transmit at maximum available power by default. Patch change again
to previous behaviour and cleanup tx power initialization.

Fortunately this is not critical fix, as mac80211 layer setup
tx power lately to 14dB, hence device does not operate at minimal
transmit power all the time.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

My commit 3598e177
"iwlwifi: fix enqueue hcmd race conditions" move hcmd callback after
command queue reclaim, to avoid call it with hcmd_lock. But since
queue read index was updated, cmd data can be overwritten. Fix problem
by calling callback before taking hcmd_lock and queue reclaim.
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>

This variable is only ever checked right after
the function that sets it, but the same function
will also return the status, so we can pass it
through instead of checking hw_ready later.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

On new hardware, ucode images always come in
pairs: code and data. Therefore, combine the
variables into an appropriate struct and use
that when both code and data are needed.

Also, combine allocation and copying so that
we have less code in total.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

The current firmware loading mechanism in
iwlwifi is very hard to follow, and thus
hard to maintain. To make it easier, make
the firmware loading synchronous.

For now, as a side effect, this removes a
number of retry possibilities we had. It
isn't typical for this to fail, but if it
does happen we restart from scratch which
this also makes easier to do should it be
necessary.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

When the firmware encounters an error while the
driver is waiting for a notification, it will
never get that notification. Therefore, instead
of timing out, bail out on errors when waiting
for notifications.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
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>

Starting the device consists of many things,
refactor out enabling the hardware and also
return -ERFKILL when the rfkill signal is
found to be asserted (which makes more sense
anyway, but is also required now to make the
__iwl_up function return right away.)
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

The iwl_down path really consists of multiple things,
refactor out the hardware resetting (including, of
course, related software state like irqs).
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

There's no point in running through iwl_down()
when we never registered with mac80211, as it
just cleans up internal structures that were
never initialised in this case. Therefore we
can also remove the special handling for this
case from __iwl_down().
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

The current code to read the error table header
just hardcodes all the offsets, which is a bit
hard to understand. We can read in the entire
header (as much as we need) into a structure,
and then take the data from there, which makes
it easier to understand. To read a bigger blob
we also don't need to grab NIC access for each
word read, making the code more efficient.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Since

commit a120e912
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Fri Feb 19 15:47:33 2010 -0800

    iwlwifi: sanity check before counting number of tfds can be free

we use skb->data after calling ieee80211_tx_status_irqsafe(), which
could free skb instantly.

On current kernels I do not observe practical problems related with
bug, but on 2.6.35.y it cause random system hangs when stressing
wireless link.

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

No longer use, remove it
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

No longer used by _agn devices, remove it
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

After driver split, no need to use ieee80211_ops, remove it
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

For bgn devices, there were no HT40 channels value in EEPROM
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Thermal throttling functions are available for all _agn devices, call the
functions directly.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

All _agn devices support continuous uCode trace, remove checking
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

When testing some new P2P code, Angie found that the
driver might crash because the beacon command ended
up being bigger than a regular command. This is quite
obvious -- a normal command is limited to roughly 360
bytes but a beacon may be much larger of course.

To fix this, use the huge command buffer.
Reported-by: NAngie Chinchilla <angie.v.chinchilla@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Since huge commands all share a single buffer,
there can only be a single one in flight at a
time since otherwise they'd overwrite each
other. This is true in the driver now, but it
seems like a possible source of bugs, so add
a test to verify that huge commands are always
sent synchronously.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

There are a number of things in the driver that
may result in a BUG(), which is suboptimal since
it's hard to get debugging information out of
the driver in that case and the user experience
is also not good :-)

Almost all BUG_ON instances can be converted to
WARN_ON with a few lines of appropriate error
handling, so do that instead.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

After driver split, no need to call led functions through callback
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>

If we maintain API properly, then there isn't
really a reason to warn about this since we'll
just be adding things that are safe to ignore,
so downgrade the warning to debug info level.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

There's no need to keep both normal and BT statistics
versions around all the time in memory when we only
use a subset of both. So keep only the subsets that
we need in memory, depending on the debug config).

Also, in doing so, we can remove all the calls to
iwl_bt_statistics() in the driver as we'll just
access the copied statistics now.

Finally, also remove this call from the one place
where it might still be needed and automatically
detect what kind of statistics the device is sending
based on their size. This way, we don't need to keep
track of which devices do what any more, which is
good since this is subject to change based on the
ucode version (as some ucode even for non-BT devices
will in fact use BT statistics).

Warn upon encountering a statistics command from the
ucode that isn't known, so we will find such issues
earlier in the future.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Tested-by: NDon Fry <donald.h.fry@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

_agn driver should perform both sensitivity and chain noise calib.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Remove the config flag for tx power calib
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Remove broken_power_save checking
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

More cleanup code, no functional changes
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

After driver split, set_l0s config is no longer needed, remove it
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Remove the reference to both 3945 and 4965 in LED code
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

More clean up after driver split
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>