There's not much point in passing priv and
hw pointers since they can be derived from
each other, and the function doesn't use
the hw pointer anyway. Remove it.
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 dump functions never access the incoming
attributes, so don't pass them.
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 function never uses the priv argument as it
only fills in the passed data, so remove the
argument.
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>

There's only one user, so the function
can be moved into the correct file. It
also loses an argument along the way.
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 function never uses its conf argument,
so remove it.
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 function has two arguments it never uses,
remove them.
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>

Track freed FW blocks during Tx. If no blocks were freed during a
predefined timeout, initiate a HW recovery. This helps in situations
when the FW watchdog fails.

Don't trigger recovery during activities that can temporarily stop
Tx. This includes:
- scanning
- buffering packets for sleeping stations (AP role)
- ROC on any role
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Add AD-HOC support to the rtl8187 based on the rtl8180 source
Signed-off-by: NAttila Fazekas <turul64@gmail.com>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

smatch was complaining:

CHECK   net/mac80211/mesh_pathtbl.c
net/mac80211/mesh_pathtbl.c:562 mesh_path_add() error: double lock
'bottom_half:'
net/mac80211/mesh_pathtbl.c:580 mesh_path_add() error: double unlock
'bottom_half:'
net/mac80211/mesh_pathtbl.c:589 mesh_path_add() error: double unlock
'bottom_half:'
net/mac80211/mesh_pathtbl.c:691 mpp_path_add() error: double lock
'bottom_half:'
net/mac80211/mesh_pathtbl.c:707 mpp_path_add() error: double unlock
'bottom_half:'
net/mac80211/mesh_pathtbl.c:716 mpp_path_add() error: double unlock
'bottom_half:'
net/mac80211/mesh_pathtbl.c:814 mesh_path_flush_by_nexthop() error:
double lock 'bottom_half:'
net/mac80211/mesh_pathtbl.c:819 mesh_path_flush_by_nexthop() error:
double unlock 'bottom_half:'
net/mac80211/mesh_pathtbl.c:887 mesh_path_del() error: double lock
'bottom_half:'
net/mac80211/mesh_pathtbl.c:901 mesh_path_del() error: double unlock
'bottom_half:'

So don't lock / unlock with _bh() while bottom halves are already
disabled.
Reported-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NThomas Pedersen <thomas@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This function is only used in iwl-scan.c, so
if we move it up a little in the file it can
be made static.
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>

Do some cleanups here:
 * remove an unused prototype
 * remove some unused constants
 * clean up includes
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It's only needed in a few places.
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>

No need to have a special config variable
for the PA type, we can just use the
additional NIC config function to config
the hardware correctly.
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>

Finally nothing needs to access priv
from shared any more, so remove it.
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 nic_config sets uCode dependent register
bits, so it must be virtual in the op_mode.
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 base packet structure will (hopefully) be
the same for all transports, but what is in it
differs. Remove the union of all the possible
contents and move the packet itself into the
transport header file. This requires changing
all users of the union to just use pkt->data.
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>

Even if the variable might also be used by other
transports, there's no need for anything outside
of the transport itself to access it, so move it
into the private area.
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>

All variables related to uCode loading (the
waitqueue and done indication) should be in
the PCI-E transport's private data as this
is transport specific. Move them there.
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 transport doesn't really need to know as
we can enforce it in the command wrapper.
Move the ucode_owner variable into priv and
do all enforcing there.
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 will be sharable, but needs to live in the
op_mode as it is dependent on command processing.
Make a library out of the notification wait code.

Since I wrote all of the code originally and only
Intel employees changed it, we can also relicense
it to dual BSD/GPL.
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>

In "iwlwifi: consolidate the start_device flow"
Emmanuel added the return if the fw isn't there
but forgot to take into account that the struct
for notification wait needs to be added only
after the check -- fix that.
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 HW configuration settings base_params, ht_params
and bt_params all should be const, make it so.
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 hardware config ht_params shouldn't be modified,
so copy the use_rts_for_aggregation parameter into
hw_params and use/modify it there.
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 is the version that can be modified, the
config params should be read-only.
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 base_params shouldn't be writable, so keep
a copy of this in priv that can be modified.
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 can be used directly from the config now.
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 is a hardware parameter, so it shouldn't
be configurable by the user. Users can disable
aggregation (which is the only thing affected)
with 11n_disable.
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 transport doesn't need to include iwl-core.h any more.
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 the command queue is full, the transport
will return -ENOSPC, but the reaction to that
depends on the op_mode. Virtualize that, the
DVM op_mode checks for CT-kill and restarts
the hardware otherwise.

We may be able to get rid of this callback by
putting the behaviour check into the wrapper
but that needs more careful evaluation.
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>

Tracing used the priv pointer as an identifier,
which has the problem that we don't have it in
all code, and also some people say no pointers
should be "leaked" to userspace.

Use the device name instead, it is more useful
anyway.
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>

They are only used in the DVM op_mode.
Also move the rfkill debug macros that
depend on them.
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>

There's no need to copy shadow_reg_enable into
hw_params since it is a pure hardware parameter
that will never change, we can access it from
the config directly.
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>

As iwl_prepare_card_hw() is idempotent (and
many cards support AMT anyway) there's no
point in calling iwl_prepare_card_hw() only
for AMT capable devices -- call it always
and simplify the code that way.
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>

That name better reflects the contents
of the file and the fact that it isn't
related to iwl-ucode.c.
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 transport layer should only check the
hardware RF kill status, not impose any
policy or reaction based on it, so move
that out of it into the op_mode.

For now keep the restriction on loading
firmware, that will have to be removed
later.
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>

Now the mutex no longer needs to be
shared, so move it into iwl_priv.
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 fact that the mutex must be held is an
implementation detail of DVM, but something
has to ensure that no two synchronous cmds
are submitted concurrently. Move the lockdep
assertion into the DVM-specific code, but
also make the transport abort if there are
two concurrently commands.

The assertion is much more useful though as
the transport check can only catch it when
it actually happens, while the assertion
makes sure it can't possibly happen.
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>

Currently, we cannot send any commands when the
uCode is in RF or CT kill, but that will not be
true for all new uCode versions, so we need to
move the check into the uCode specific code.

Also remove the duplicate rfkill check.
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>