Changed iwl_firmware_pieces structure to support an array of
separate images, and an array of sections for each image.
In fw_sec and fw_desc structures, added a field for
offset from the HW address, to support 16.0 uCode that
provides an offset instead of any other data about the section.
This field is filled with default values when parsing instruction
or data section.
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>
Remove IWL_UCODE_NONE from enum iwl_ucode_type which,
by being the default value in 0-initialized memory,
implicitly allowed us to track whether any uCode had
ever been loaded successfully (which would have been
the INIT uCode) and instead explicitly track whether
or not INIT uCode has been run.
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>
This wait queue really belongs to the transport
layer, as it is used for sending synchronous
commands to the HW.
However, only op_mode knows about errors and
exceptional conditions, so make this queue
accessible by the 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>
BIg portion of "iwlwifi: remove max_txq_num from hw_params" was
missing during merge, here is the fix for it.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The command queue number is required by the transport
layer, but it can be determined only by the op mode.
Move this parameter to the dvm op mode, and configure
the transport layer using an API.
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>
Hardware parameters will be shared, so
move the definitions into the shared
header file.
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>
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: 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>
Finally nothing needs to access priv
from shared any more, so 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 nic_config sets uCode dependent register
bits, so it must be virtual in the op_mode.
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>
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: 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 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: 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 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: 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 configuration settings base_params, ht_params
and bt_params all should be const, make it so.
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 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: 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 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: 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>
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: 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>
They are only used in the DVM op_mode.
Also move the rfkill debug macros that
depend on them.
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>
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: 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>
Now the mutex no longer needs to be
shared, so move it into iwl_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>
This file was recently introduced, but then
directly abused -- it contained private data
that shouldn't have been used by anything
but the implementation of firmware requests
and some very core code. Now that it is no
longer accessed by any code but the code in
iwl-drv.c, we can dissolve it.
Also rename the iwl_nic struct to iwl_drv to
better reflect where and how it is used.
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>
Through the driver, struct iwl_fw will
store the firmware. Split this out into
a separate file, iwl-fw.h, and make all
other code use it. To do this, also move
the log pointers into it, and remove the
knowledge of "nic" from everything.
Now the op_mode has a fw pointer, and
(unfortunately) for now the shared data
also needs to keep one for the transport
to access dump the error log -- I think
that will move later.
Since I wanted to constify the firmware
pointers, some more changes were needed.
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>
uCode loading belongs to the op_mode, as it
is dependent on various things there and the
commands sent during it are specific to it.
Move the prototypes to iwl-agn.h to indicate
this. To make this possible, also move all
the calibration handling (which is op_mode
dependent after all).
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 is used from there, so should be in 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>
These are DVM specific, and shouldn't be
in iwl-shared.h.
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>
Only used in two places in the same file,
no need to be in iwl-shared.h.
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>
Currently, queue mapping is handled in the
transport. This may change, but until then
the code for it can be close to where it's
used rather than in iwl-shared.h.
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 is how the transport passes things
up into higher layers, so it belongs to
the transport API.
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>
iwl_queue_inc_wrap/iwl_queue_dec_wrap aren't
shared functions, they are PCI-E specific,
so move them into the appropriate header.
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>
struct iwl_rx_mem_buffer implementation details
(DMA address, list pointers) that the upper
layers don't need. Introduce iwl_rx_cmd_buffer
that is passed upstream and only contains the
needed data (the page). Additionally, access
this data only via accessor functions, allowing
us to change the implementation in the future.
These accessors are rxb_addr() (as before) and
rxb_steal_page() to take ownership of the data.
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>
When CMD_WANT_SKB is set for a (synchronous)
command, the response is passed back to the
caller which is then responsible for freeing
it. Make this more abstract with real API,
passing directly the response packet in the
new cmd.resp_pkt member and also introduce
iwl_free_resp() to free the pages -- this
way the upper layers don't have to directly
touch the page implementation.
NOTE: This breaks IDI -- the new code isn't reflected there yet!
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>
With the new WoWLAN flow into the transport
there no longer is a need for this to be
shared, so move it into 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>
Writing to the global config structures
is always wrong. To protect against such
mistakes in the future, mark them const.
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>
There's no SKU override, we always just use
it from EEPROM. As such, we can remove it
from the config and use it in hw_param only.
Since iwl_eeprom_check_sku() really needs
to fill it in also rename that to
iwl_eeprom_init_hw_params().
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>
There's no need for the per-device debug
level that we expose in debugfs since the
module parameter is writable in sysfs.
At the same time, simplify code by changing
iwl_get_debug_level(shrd) & IWL_DL_ISR)
to
iwl_have_debug_level(IWL_DL_ISR)
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>
Some data doesn't need protection, some of the
lock places are simply useless, and some data
can be protected with the mutex instead. Thus
the shared lock can be removed by making those
changes.
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>
Now that the transport has its own locking,
there's no need to have the sta_lock in the
shared data. Also, it can be a BH lock as
it's not used from IRQ handlers.
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>
Export it as "nic_error" notification, the error handling will be in
the op_mode.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Export it as "hw_rf_kill" notification.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Export them as "queue_full" and "queue_not_full" notification.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
This handler allows the transport layer to free an skb from the
op_mode. This can happen when the driver is stopped while Tx
packets are pending in the transport layer.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Define the op_mode as an interface with its ops. All the functions
of the op_mode are "private", but its ops is made public in
iwl-op-mode.h.
The drv object starts the op_mode by using the start function in the
public ops.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
iwl_remove stops the wifi flows, so rename.
Moreover, we can possibly stop the wifi flows even if the driver
is statically compiled in the kernel, so remove the __devexit pragma.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Fetch the fw and spawn the op_mode. The op_mode that we need
to fetch is determined from the fw file.
Since the fw is fetched very early in the init flow, we can
determine what op_mode to spawn.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
This will allow to have different behavior depending on the fw.
Different fw APIs require completely different implementation
of the mac80211 APIs. Each of these implementations is called an
op_mode.
The current op_mode is called DVM which states for dual virtual MAC.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
This will allow to set the hw_params after we fetch the uCode.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
David Spinadel