Support explicit monitor interface to keep
injection working after the HW queue changes.
This also finally enables sniffer mode.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This doesn't make any sense. Init it from the transport instead.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
There are various problems happened on 5GHz band not observed on
2.4 GHz (microcode errors, queue stuck, etc... ) . Also roaming
between 5GHz AP and 2GHz does not work very well. To workaround
the problems add option to disable 5GHz support. This will help
on environments where APs are dual-band, and devices will not try
to associate on band where issues happen.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Also remove a debug print when allocation error occurred.
The kernel will complain anyway.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Conflicts:
drivers/net/ethernet/intel/e1000e/param.c
drivers/net/wireless/iwlwifi/iwl-agn-rx.c
drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c
drivers/net/wireless/iwlwifi/iwl-trans.h
Resolved the iwlwifi conflict with mainline using 3-way diff posted
by John Linville and Stephen Rothwell. In 'net' we added a bug
fix to make iwlwifi report a more accurate skb->truesize but this
conflicted with RX path changes that happened meanwhile in net-next.
In e1000e a conflict arose in the validation code for settings of
adapter->itr. 'net-next' had more sophisticated logic so that
logic was used.
Signed-off-by: David S. Miller <davem@davemloft.net>
For now at least, all module parameters should be
with the core functionality, so move them there,
while at it rename to iwlwifi_mod_params. Also
rename iwl-shared.h to iwl-modparams.h to reflect
the real contents.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
These defines will have to be shared
between modules, but they seem better
placed in iwl-drv.h than iwl-shared.h.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Keeping statistics per frame type really isn't
very useful, and needs a huge amount of code
so remove it. Since that is the only thing in
iwl-core.{c,h} now, those files can be killed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
This is superseded by tracing and no longer needed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Since the op_mode may go away, the transport needs to be able to
be told not to update the op_mode at all (even for RF kill).
Provide this API and use it in the proper places.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
ctx->vif is dereferenced in different part of iwlwifi code, so do not
nullify it.
This should address at least one of the possible reasons of WARNING at
iwlagn_mac_remove_interface, and perhaps some random crashes when
firmware reset is performed.
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Each modules will hold a pointer to struct device instead.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Instead of using the shared area that we be killed.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Instead of using the shared area that we be killed.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
The command strings are needed through the layers for
debug and error messages, but can differ with opmode.
As a result, we need to give the command names to the
transport layer as configuration.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
To support hybrid state of MVM op_mode, most of the functioanallity
will be done using DVM functions.
When MVM will have independant live, the declarations will be removed
and the functions will be static back.
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
We've never released firmware using the alternatives
mechanism and our build process makes that difficult
anyway. This means that in every file we have ever
built (except maybe by hand for testing) the listed
alternative was 0. Make the alternative field in the
TLVs part of the TLV number (thus expanding that to
32 bits); this gives us more TLV numbers (not really
needed) and more importantly protects against rogue
firmware files that actually do use the alternatives
mechanism -- those will now be rejected since they
don't contain any valid TLVs.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
My original idea with this was to adjust the sleep
pattern of the uCode based on the maximum network
latency userspace asked for. Due to nobody wanting
to test it, this logic was disabled by default. It
seems the time has come to remove it, since it's
not only always disabled but there also don't seem
to be any applications that actually request a max
network latency.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Move this as part of iwl-core.c cleanup.
Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Move this as part of iwl-core.c cleanup.
Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Move this as part of iwl-core.c cleanup.
Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
iwl_set_hw_rfkill_state is used only in
iwl-agn.c. Move it there and mark it static.
Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
iwl_free_skb is used only in iwl-agn.c, move
it there and mark it static.
Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Not all stations are guaranteed to have the same
active (available) legacy rates, so calculate them
on rate control init instead of hard-coding them
based on our own available rates. I have no idea
why that was done here before.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Having the pointer to lib_ops in the config
makes it impossible to split the driver into
different modules. Determine the ops based on
the device family enumeration to get rid of
the direct pointer.
Also move all the opmode specific code from
the iwl-[1256]000.c files into a new file
iwl-agn-devices.c so that the former only
have configuration data now.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The whole code around eeprom is distributed
across whole bunch of different files, most
of which belong to the to-be-DVM code. As a
result, it is currently very hard to split
out the EEPROM code to be generic. However,
it is also quite unlikely that the current
EEPROM code will be needed by the MVM code
as that has different mechanisms to query
the EEPROM (it does so through the uCode.)
So, at least temporarily, move everything
into priv. If it becomes necessary to use
the code from MVM, we will have to split it
out, but then it's also easier since we'll
know what pieces we need.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Split the force_reset debugfs file into two
different files:
* "rf_reset" triggers a reset of the RF when
written to and exposes statistics on RF
resets when read
* fw_restart triggers a firmware restart when
written to and lives in the transport
This cleans up all sources of firmware restart
to originate within the transport layer and
allows us to simplify some code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This defaults to false, and we don't recommend
to use it anywhere, so just remove it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The hw_params are mostly values that are
derived from the actual hardware config.
As such, while it is possible that MVM
will require similar ones, it makes more
sense -- at least for now -- to put them
into the DVM struct.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This removes one of the two sources of device
restarts in the upper layer -- those are a bit
inconvenient because normal restarts originate
in the transport. By moving the watchdog down
it can be treated the same.
Also rewrite the watchdog logic. Timers are
much more efficient when they never fire, so
instead firing a timer every 500ms set up a
timer for each TX queue and fire it only when
the queue is really stuck. This avoids the CPU
waking up when everything is working well.
While at it, remove the wd_disable config item
and replace it by simply setting wd_timeout to
IWL_WATCHHDOG_DISABLED (0).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
That way it isn't needed in hw_params, which
is shared data. It also isn't really what we
should configure in the transport, that is
better just 4k/8k, so configure a bool and
derive the page order in the transport. This
also means the transport doesn't need access
to the module parameter any more.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Prefix dmesg output with "iwlwifi: " by
adding #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The op_mode should check for FW_ERROR before calling send_cmd. This
removes the need to test for FW_ERROR in the trans layer.
Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
With error logging now completely handled in
the op_mode, the transport layer does not
need to know information about the loaded
firmware.
Remove this state information from the
iwl_shared data structure.
Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is used only in one file, move it there
and make it static.
Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This variable holds the ucode currently
running on the device; which is determined by
op_mode, so move this parameter there.
Also, the name of the variable is a bit
misleading, so rename it to cur_ucode.
Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Error log reporting does not belong to the
transport layer, but to the op_mode loading
the ucode, as it is the entity which knows
about the ucode loaded, and what the error
information means.
Move device logging pointers from the
transport layer to op_mode.
With this change, transport layer only
reports an error to the op_mode, which will
figure out what to do with the error. This
causes the driver to now dump out error logs
when the command queue is stuck as well.
Also, move the debugfs entry for event logs
out of the transport layer and into op_mode.
Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
iwl_nic_error is used in iwl-agn.c only, move
it there and make it static.
Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In the process, make iwlagn_fw_error
a non-static function, as it is used
by more than one file.
Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
No other component is accessing it any more,
so it can move to the correct place in priv.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The queue mapping is not only dynamic, it
is also dependent on the uCode, as we can
already see today with the dual-mode and
non-dual-mode being different.
Move the queue mapping out of the transport
layer and let the higher layer manage it.
Part of the transport configuration is how
to set up the queues.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
get rid of un-needed parameter
Change-Id: I992741e7382a3dbced7f8413bf1d5f301029d576
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Printing the SRAM and similar testmode operations could
be triggered when no uCode is loaded; prevent those
invalid operations by tracking whether uCode is loaded.
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
