We use priv->mutex to avoid race conditions between iwl_chswitch_done()
and iwlagn_mac_channel_switch(), when marking channel switch in
progress. But iwl_chswitch_done() can be called in atomic context
from iwl_rx_csa() or with mutex already taken from iwlagn_commit_rxon().
These bugs were introduced by:
commit 79d0732550
Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date: Thu May 6 08:54:11 2010 -0700
iwlwifi: support channel switch offload in driver
To fix remove mutex from iwl_chswitch_done() and use atomic bitops for
marking channel switch pending.
Also remove iwl2030_hw_channel_switch() since 2000 series adapters are
2.4GHz only devices.
Cc: stable@kernel.org # 2.6.36+
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>
For 6150 devices, modify the supported PCI subsystem ID.
Cc: stable@kernel.org
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
No functional changes, just logging more information when uCode crash, also
change change the format.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
The current "huge" command handling is a bit
confusing, and very limited since only one
command may be huge at a time. Additionally,
we often copy data around quite pointlessly
since we could instead map the existing scan
buffer for example and use it directly.
This patch makes that possible. The first
change is that multiple buffers may be given
to each command (this change was prepared
earlier so callsites don't need to change).
Each of those can be mapped attached to a TB
in the TFD, and the command header can use a
TB (the first one) in the TFD as well.
Doing this allows getting rid of huge commands
in favour of mapping existing buffers. The
beacon transmission is also optimised to not
copy the SKB at all but use multiple TBs.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
All of these functions no longer need to be
accessed indirectly since they're shared in
all AGN devices.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
In a subsequent patch, I want to make commands use
multiple TBs in a TFD. This is a simple change to
prepare the data structures for this, with as of
now still just a single TB supported.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
The frame pre-allocation is quite a bit of complex
code, all to avoid a single allocation. Remove it
and consolidate the beacon sending code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
This patch adds the feature to support the test mode operation through
the generic netlink channel NL80211_CMD_TESTMODE between intel
wireless device iwlwifi and the user space application svtool.
The main purpose is to create a transportation layer between the iwlwifi
device and the user space application so that the interaction between the
user space application svtool and the iwlwifi device in the kernel space is
in a way of generic netlink messaging.
The detail specific functions are:
1. The function iwl_testmode_cmd() is added to digest the svtool test command
from the user space application. The svtool test commands are categorized to
three types : commands to be processed by the device ucode, commands to access
the registers, and commands to be processed at the driver level(such as reload
the ucode). iwl_testmode_cmd() dispatches the commands the corresponding handlers
and reply to user space regarding the command execution status. Extra data is
returned to the user space application if there's any.
2. The function iwl_testmode_ucode_rx_pkt() is added to multicast all the spontaneous
messages from the iwlwifi device to the user space. Regardless the message types,
whenever there is a valid spontaneous message received by the iwlwifi ISR,
iwl_testmode_ucode_rx_pkt() is invoked to multicast the message content to user
space. The message content is not attacked and the message parsing is left to
the user space application.
Implementation guidelines:
1. The generic netlink messaging for iwliwif test mode is through NL80211_CMD_TESTMODE
channel, therefore, the codes need to follow the regulations set by cfg80211.ko
to get the actual device instance ieee80211_ops via cfg80211.ko, so that the iwlwifi
device is indicated with ieee80211_ops and can be actually accessed.
Therefore, a callback iwl_testmode_cmd() is added to the structure
iwlagn_hw_ops in iwl-agn.c.
2. It intends to utilize those low level device access APIs from iwlwifi device driver
(ie. iwlagn.ko) rather than creating it's own set of device access functions.
For example, iwl_send_cmd(), iwl_read32(), iwl_write8(), and iwl_write32() are reused.
3. The main functions are maintained in new files instead of spreading all over the
existing iwlwifi driver files.
The new files added are :
drivers/net/wireless/iwlwifi/iwl-sv-open.c
- to handle the user space test mode application command
and reply the respective command status to the user space application.
- to multicast the spontaneous messages from device to user space.
drivers/net/wireless/iwlwifi/iwl-testmode.h
- the commonly referenced definitions for the TLVs used in
the generic netlink messages
Signed-off-by: Cindy H. Kao <cindy.h.kao@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
All agn devices use the same module parameter structure. Delete the
indirection and access the structure diretly.
Signed-off-by: Don Fry <donald.h.fry@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
New microcode versions use the good CRC threshold
field differently, as a flag, and in that case we
should set it to 1/0 instead of 1/65535 for an
active/passive scan.
The new behaviour is advertised by the uCode with
a feature flag.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
The WoWLAN resume code will have to essentially
do a restart, but without going through the work
struct. To support that, refactor the restart by
splitting out the preparation code into a new
function.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Since
commit f844a709a7
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Fri Jan 28 16:47:44 2011 +0100
iwlwifi: do not set tx power when channel is changing
we set device tx power during initialization to priv->tx_power_next,
which itself is initialized to minimum power. That changed
default behaviour of driver. Previously we initialized device to
transmit at maximum available power by default. Patch change again
to previous behaviour and cleanup tx power initialization.
Fortunately this is not critical fix, as mac80211 layer setup
tx power lately to 14dB, hence device does not operate at minimal
transmit power all the time.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This variable is only ever checked right after
the function that sets it, but the same function
will also return the status, so we can pass it
through instead of checking hw_ready later.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
On new hardware, ucode images always come in
pairs: code and data. Therefore, combine the
variables into an appropriate struct and use
that when both code and data are needed.
Also, combine allocation and copying so that
we have less code in total.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
The current firmware loading mechanism in
iwlwifi is very hard to follow, and thus
hard to maintain. To make it easier, make
the firmware loading synchronous.
For now, as a side effect, this removes a
number of retry possibilities we had. It
isn't typical for this to fail, but if it
does happen we restart from scratch which
this also makes easier to do should it be
necessary.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
A notification wait function is called with the
command, but currently has no way of passing
data back to the caller -- fix that by adding a
void pointer to the function that can be used
between the caller and the function.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Starting the device consists of many things,
refactor out enabling the hardware and also
return -ERFKILL when the rfkill signal is
found to be asserted (which makes more sense
anyway, but is also required now to make the
__iwl_up function return right away.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
The iwl_down path really consists of multiple things,
refactor out the hardware resetting (including, of
course, related software state like irqs).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
There's no point in running through iwl_down()
when we never registered with mac80211, as it
just cleans up internal structures that were
never initialised in this case. Therefore we
can also remove the special handling for this
case from __iwl_down().
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
The current code to read the error table header
just hardcodes all the offsets, which is a bit
hard to understand. We can read in the entire
header (as much as we need) into a structure,
and then take the data from there, which makes
it easier to understand. To read a bigger blob
we also don't need to grab NIC access for each
word read, making the code more efficient.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
When testing some new P2P code, Angie found that the
driver might crash because the beacon command ended
up being bigger than a regular command. This is quite
obvious -- a normal command is limited to roughly 360
bytes but a beacon may be much larger of course.
To fix this, use the huge command buffer.
Reported-by: Angie Chinchilla <angie.v.chinchilla@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
There are a number of things in the driver that
may result in a BUG(), which is suboptimal since
it's hard to get debugging information out of
the driver in that case and the user experience
is also not good :-)
Almost all BUG_ON instances can be converted to
WARN_ON with a few lines of appropriate error
handling, so do that instead.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
If we maintain API properly, then there isn't
really a reason to warn about this since we'll
just be adding things that are safe to ignore,
so downgrade the warning to debug info level.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
There's no need to keep both normal and BT statistics
versions around all the time in memory when we only
use a subset of both. So keep only the subsets that
we need in memory, depending on the debug config).
Also, in doing so, we can remove all the calls to
iwl_bt_statistics() in the driver as we'll just
access the copied statistics now.
Finally, also remove this call from the one place
where it might still be needed and automatically
detect what kind of statistics the device is sending
based on their size. This way, we don't need to keep
track of which devices do what any more, which is
good since this is subject to change based on the
ucode version (as some ucode even for non-BT devices
will in fact use BT statistics).
Warn upon encountering a statistics command from the
ucode that isn't known, so we will find such issues
earlier in the future.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Tested-by: Don Fry <donald.h.fry@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>
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>
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>
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>
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>
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>
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>
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 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>
Stanislaw Gruszka