Add support for extended command id in notification system.
Extended command id header contains group id in addition to command id.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The assumption before this patch was that we don't need to
run again the INIT firmware after the system booted. The
INIT firmware runs calibrations which impact the physical
layer's behavior.
Users reported that it may be helpful to run these
calibrations again every time the interface is brought up.
The penatly is minimal, since the calibrations run fast.
This fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=94341

CC: <stable@vger.kernel.org>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Different queue can have different behavior. While it can be
unacceptable for a certain queue to be stuck for 2 seconds
(e.g. the command queue), it can happen that another queue
will stay stuck for even longer (a queue servicing a power
saving client in GO).
The op_mode can even make the timeout be a function of the
listen interval.
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

CMD_SYNC is really 0 which is confusing:

if (cmd.flags & CMD_SYNC) is always false.
Fix this by simply removing its definition.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Add an inline helper function for getting an RX packet's
length or payload length and use it throughout the code
(most of which I did using an spatch.)

While at it, adjust some code, and remove a bogus comment
from the dvm calibration code.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Reviewed-by: NEran Harary <eran.harary@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

None of these files are actually using any __init type directives
and hence don't need to include <linux/init.h>.  Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Acked-by: NChristian Lamparter <chunkeey@googlemail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Happy new year!
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

If the firmware image that we attempt to load doesn't
actually exist we have a broken firmware file or other
code not checking things correctly, so warn in such a
case. Also avoid assigning cur_ucode/ucode_loaded then.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

There are a number of parameters that aren't really hardware
specific but rather define how the DVM firmware is used.
Move these into the DVM configuration.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There is a race between the restart flow and the workers.
The workers are cancelled after the fw is already killed
and might send HCMD when there is fw to handle them.
Simply check that there is a fw to which the HCMD can be
sent before actually sending it.

Cc: stable@vger.kernel.org
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

7000.c was released as GPL only by mistake: it should be
dual licensed - GPL / BSD.
The file that contains the license in the kernel is COPYING
and not LICENSE.GPL.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Update Copyright notices to 2013.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In some cases, the fw should run even if the NIC is in
RFKILL. Make the API more flexible to allow that.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

No need to verify that the fw has been written correctly.
In case it hasn't, we won't get ALIVE notification.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since we will have several forms of NVM (EEPROM, OTP, etc.)
and they will have different layouts, make the parsed data
more generic. This allows functional code to be independent
of a specific layout.

Also change some variables and function names from having
"eeprom" to "nvm" in their name.
Signed-off-by: NEytan Lifshitz <eytan.lifshitz@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The ALIVE response of new fw inclues the base address of
the SCD in SRAM. Until we read it from a prph register,
which was set by the fw. Since the fw might well stop
updating the prph register, add a WARN when there is an
inconsitency between the ALIVE response and the register
to catch any change in the behavior.
Reviewed-by: NGregory Greenman <gregory.greenman@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Instead of allocating one big chunk of DMA-coherent
memory for the firmware and keeping it around, only
vmalloc() the firmware and copy it into a single
page of DMA-coherent memory for the upload.

The advantage is that we don't need DMA memory for
the firmware image that is stored while the driver
is operating, we only need it while uploading.

This will make it easier for the driver to work if
the system has fragmented memory.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since the op_mode defines the queue mapping, let it do it
completely through the API functions.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The EEPROM reading/parsing code is all mixed in
the driver today, and the EEPROM is parsed only
when we access data from it. This is problematic
because the NVM needs to be parsed and that is
independent of reading it. Also, the NVM format
for new devices will be different and probably
require a new parser.

Therefore refactor the reading and parsing and
create two independent components. Reading the
EEPROM requires direct hardware accesses and
therefore access to the transport, but parsing
is independent and can be done on an NVM blob.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since we're working on another mode/driver
inside iwlwifi, move the current one into a
subdirectory to more cleanly separate the
code. While at it, rename all the files.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

A lot of functions were temporarily made non-static
for experimental work, make them static again now.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@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: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Instead of using the shared area that we be killed.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Instead of using the shared area that we be killed.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NWey-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: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.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: 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 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: NMeenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn 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: NMeenakshi Venkataraman <meenakshi.venkataraman@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 device using this mechanism.
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 calibration results all come in while we're
waiting for the calibration complete notification.
As a consequence, there's no need to install a
global RX handler for them, we can use the newly
extended notification wait framework for this and
make the code easier to follow.

It is now quite explicit that we are processing
the calibration results while waiting for the
complete notification, before this was implicit
and developers had to know this to understand why
we wait for the calibration complete notification
and what happens while we wait.
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>

Sometimes, for example when we ask the uCode
for calibration, we wait for the "complete"
response while we also need the results that
are sent in other, interim, notifications.

Currently we handle this by installing an RX
handler globally, but that isn't needed as
this is the only time we want to use these
notifications.

So in order to be able to simplify at least
future code that does the same, extend the
notification wait framework to allow you to
wait for multiple commands and decide based
on the command whether the wait finished.

While at it, also fix a race that can then
become relevant -- if the wait function has
returned true once it shouldn't be called
again, today this can happen due to races
between the triggering and the wakeup.
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>

Change iwl_fw struct to hold an array of fw_img instead of
three separated instances.

Change fw_img to hold an array of fw_desc instead of two
separate descriptors for instructions and data.

Change load_given_ucode, load_section, verification functions
etc. to support this structure.
Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn 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: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn 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: NDavid Spinadel <david.spinadel@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Otherwise we are not able to run more than one device per driver:

[   24.743045] kmem_cache_create: duplicate cache iwl_dev_cmd
[   24.743051] Pid: 3165, comm: NetworkManager Not tainted 3.3.0-rc2-wl+ #5
[   24.743054] Call Trace:
[   24.743066]  [<ffffffff811717d5>] kmem_cache_create+0x655/0x700
[   24.743101]  [<ffffffffa03b9f8b>] iwl_alive_notify+0x1cb/0x1f0 [iwlwifi]
[   24.743111]  [<ffffffffa03ba442>] iwl_load_ucode_wait_alive+0x1b2/0x220 [iwlwifi]
[   24.743142]  [<ffffffffa03ba893>] iwl_run_init_ucode+0x73/0x100 [iwlwifi]
[   24.743152]  [<ffffffffa03b8fa1>] __iwl_up+0x81/0x220 [iwlwifi]
[   24.743161]  [<ffffffffa03b91c0>] iwlagn_mac_start+0x80/0x190 [iwlwifi]
[   24.743188]  [<ffffffffa03307b3>] ieee80211_do_open+0x293/0x770 [mac80211]
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
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 PASSIVE_NO_RX workaround currently crosses
through the op_mode and transport layers, which
is a bit odd. This also isn't necessary, if the
transport simply reports when queues are full
(or no longer full) the op_mode can keep track
of this state, and report to mac80211 only what
*it* thinks is appropriate. What is appropriate
can then be based on whether queues should be
stopped to wait for RX or not.

This significantly simplifies the transport API,
it no longer needs to expose anything to stop a
queue, nor to wake "any" queue, this can all be
handled in the upper layer completely.

Also simplify the handling to not be dependent
on the context, that makes little sense as the
queues are shared and both contexts have to be
on the same channel 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>

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>

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>

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>