define of firmware filenames use extra macro to build the files name.
Signed-off-by: Jay Sternberg <jay.e.sternberg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
This generates a massive reduction in module size:
with debug:
text data bss dec hex filename
670300 13136 420 683856 a6f50 iwlagn.ko (before)
388347 13136 408 401891 621e3 iwlagn.ko (after)
without debug:
text data bss dec hex filename
528575 13072 420 542067 84573 iwlagn.ko (before)
294192 13072 408 307672 4b1d8 iwlagn.ko (after)
This also removes all the IO debug functionality since
it can easily be replaced by tracing, and makes the
code unnecessarily complex.
I haven't done any CPU utilisation measurements, but
given that the hotpaths don't use much IO it is not
likely to have a negative impact; in fact, the size
reduction will reduce cache pressure which possibly
improves performance.
Finally, an unused function or two were removed.
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 ISR (interrupt service routine) ops are now
no longer necessary since they are the same for
all devices this driver now handles.
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>
We never use the value in alloc_rxb_page,
so there's no point in keeping it either.
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 rev_id variable is only printed, we
don't need to store 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_rev variable is used only during init,
so there's no need to keep it around.
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 variable is never 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>
Again, a 4965 specific code path that we no
longer need in iwlagn.
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>
We know after loading the ucode whether it will
support PAN or not, so we can also initialise
the cmd_queue variable much earlier.
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>
Devices newer than 4965 don't actually send
two different versions of the ALIVE command,
so we always had a bug here since before this
patch we copy more data than we got. Remove
the iwl_init_alive_resp struct and don't use
it.
Since we also really don't need to track all
the data received in ALIVE as we only use the
error and log event tables later, we can also
save space by just keeping those and not more
data around in memory.
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>
My previous patch left a message talking about
bootstrap, but that's clearly bogus.
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 new devices and microcode files will a greater
variety of features, so the TLV-per-feature approach
we took before will quickly make things harder to
manage and increase the file size.
Add a new TLV that has feature flags. Currently, it
will contain:
1) a PAN feature flag, which moves from a separate
TLV
2) a new BT stats bit that indicates whether the
microcode image uses bluetooth statistics
3) a new MFP flag for management frame protection
which can be enabled once the device/microcode
supports 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>
In alive notify, we should check return code instead of assume everything ok
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This was used only on 4965 in conjunction with
the bootstrap ucode.
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 ucode restart has to take into account a number
of things, like clearing the HCMD_ACTIVE and other
status bits, and waking up the wait_command_queue.
Currently, however, there are a number of places
that neither do that, nor actually set the FW error
bit that leads to proper restart handling, which
means that in those cases things will probably just
hang completely.
To clean this up, make all ucode restart go through
a single function, except for the cases where it's
called during firmware loading.
Also fix a bug in wimax coexist restart avoidance,
it needs to first clear the status bits (and it has
to clear the HCMD_ACTIVE one as well) and then wake
up anything waiting on wait_command_queue.
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 4965 had a bootstrap microcode image, so
the agn driver can completely ignore that and
we can remove some code from 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>
When we loaded a ucode, there's no point in
checking any one that is present, we know
which one is supposed to be present so also
verify that it is exactly the right one.
That also simplifies the code and makes it
faster since it doesn't have to check 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>
The code in iwlcore_verify_inst_sparse really
doesn't need to keep track of the number of
errors it encountered since a single one is
fatal.
Also, the code in iwl_verify_inst_full is just
used to print out some things, so rename it to
iwl_print_inst and don't give it a return code
and just make it print out the values.
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>
In alive notification call, return the status from iwl_send_calib_results()
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
A number of places just use a variable to return
it right away, which is useless, so let's remove
the variables 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>
All agn devices behave the same, so there's no
need to go through function pointers for any
of the ucode loading functionality.
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 these handlers are no longer shared
between 4965 and agn, they can be static.
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 driver was split, a bunch of definitions
for the 3945 and 4965 devices stayed around, but
they're now useless so remove (some of) 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>
Some code was removed, but a variable it used
and that is now unused stayed around, kill 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>
We now use priv->mutex to serialize sync command, remove old
priv->sync_cmd_mutex and add assertion that priv->mutex must be locked.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Check status bits with mutex taken, because when we wait for mutex
unlock, status can change. Patch should also make remaining sync
commands be send with priv->mutex taken. That will prevent execute
these commands when we are currently reset firmware, what could
possibly cause troubles.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We mark command as huge by using meta->flags from other (non huge) command,
but flags can be possibly overridden, when non huge command is enqueued,
what can lead to:
WARNING: at lib/dma-debug.c:696 dma_debug_device_change+0x1a3/0x1f0()
DMA-API: device driver has pending DMA allocations while released from device [count=1]
To fix introduce additional CMD_MAPPED to mark command as mapped and
serialize iwl_enqueue_hcmd() with iwl_tx_cmd_complete() using
hcmd_lock. Serialization will also fix possible race conditions,
because q->read_ptr, q->write_ptr are modified/used in parallel.
On the way fix whitespace.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
At least EEPROM version 0x11A has the wrong
number of chains programmed into it for some
reason, so we need to override in the driver.
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>
A number of these devices have appeared "in the wild", and apparently
the Windows driver is perfectly happy to support this EEPROM version.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: stable@kernel.org
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
We initialize exit_pending twice. It's the second initialization which
is correct. That was added in d745d472af "iwlwifi: cancel scan when
down the device".
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This gives much better performance at fast 3x3 rates (up to ~160 Mbps).
The scheduler will still make most decisions about batch size based on
available packets and RX parameters.
Signed-off-by: Daniel Halperin <dhalperi@cs.washington.edu>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Throughout the code we use rate_n_flags & 0xff to extract the lower byte
of the rate_n_flags u32 that contains the information about the rate.
Add a #define and remove the use of the magic number.
Signed-off-by: Daniel Halperin <dhalperi@cs.washington.edu>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Since the driver split, there's no need for no_agg_framecnt_info since
all devices have this set to false. Secondly, the compressed block ack
handling code was broken. Fix this.
(1) A shift less than zero simply implies that the buffer wrapped, this
is expected. Remove the incorrect comment.
(2) The (agg->frame_count > (64-sh)) condition can happen if the last
frame is dropped. E.g., if I send 7 frames and the 6th is received but
the 7th is lost, the other side may only shift the window 6, not 7
frames since the last bit is a 0. This is perfectly fine behavior and
doesn't invalidate the feedback.
(3) Store the feedback from a Compressed BA in the first newly received
frame, rather than the start of the window. This way it will get
processed by the rate selection code. Feedback stored in a non-received
frame is likely to get overwritten by the retransmission.
This is based on the approach taken by minstrel_ht.
Signed-off-by: Daniel Halperin <dhalperi@cs.washington.edu>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
When filling out its rate scale table, iwlwifi repeats the first HT rate
IWL_HT_NUMBER_TRY times. The hardware scheduler will stop using
aggregation for any frame that fails LINK_QUAL_AGG_DISABLE_START_DEF
times. Currently, both these constants equal 3.
If iwlwifi probes a faster rate than the link supports, all frames in a
(potentially tens of frames large) batch will fail IWL_HT_NUMBER_TRY
times. Because this happens to be as large as
LINK_QUAL_AGG_DISABLE_START_DEF, all frames will then be sent
individually. This leads to a short, but performance-degrading window
where the legacy stop-and-wait MAC takes over.
Bounding the initial rate by (LINK_QUAL_AGG_DISABLE_START_DEF-1)
attempts makes the third try use a lower rate and hence more be likely
to succeed. This somewhat mitigates the above described behavior.
Signed-off-by: Daniel Halperin <dhalperi@cs.washington.edu>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
iwlagn's hardware scheduler needs to be set up
with the right aggregation frame limit and
buffer sizes. To achieve this, we need to move
the hardware queue setup to when the session
becomes operational.
Tested-by: Daniel Halperin <dhalperi@cs.washington.edu>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Since the driver split, there's no need for
function pointers any more for aggregation
queue setup and teardown as all devices now
share the same code. Simplify this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Clearly a mistake, since pointers won't suddenly
change their value...
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We should unlock here instead of returning -EINVAL directly.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
