The effect of using a short single-channel scan
to reset the radio is that scanning a channel
that isn't in use needs to re-tune the radio.
This means that the dwell time is irrelevant,
so use a shorter time.

While at it, clean up the code for this a bit.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

My commit 26a7ca9a ("iwlwifi: refactor EEPROM reading/parsing")
broke the 11n_disable module parameter's BIT(0) to disable all HT
operation (using the other bits to disable aggregation only was
unaffected). Restore this by overriding the SKU when parsing the
EEPROM if the module parameter is set.
Reported-by: NMatthijs Kooijman <matthijs@stdin.nl>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When the device is doing an internal radio reset
scan, ROC can be rejected to the supplicant with
busy status which confuses it.

One option would be to queue the ROC and handle
it later, but since the radio reset scan is very
quick we can just wait for it to finish instead.

Also add a warning since we shouldn't run into
the case of having a scan active when requesting
a ROC in any other case since mac80211 will not
scan while ROC or ROC while scanning.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This feature needs to be disabled for all NICs.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This variable was accessed without taking the lock.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This is really not needed, we already have a lock inside
the accesses to the prph.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This is not needed since notif_wait_lock is never accessed
from IRQ.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This is required by the op_mode API.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

A few op_mode of the op_mode API functions have requirements
on the running context of the caller. Document that.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This flow can actually happen due to a corner case in
mac80211: the station is deleted before we get a chance
to reclaim all the packets in flight in AGG queue.
The tid_data for this station is zeroed, and we lose
the match with the Tx queue.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since request_module_nowait() can't be backported
use request_module() instead -- we don't need the
asynchronous behaviour of request_module_nowait()
here since we're running in the firmware request
work struct.
Tested-by: NDonald H Fry <donald.h.fry@intel.com>
Reviewed-by: NDonald H Fry <donald.h.fry@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Due to commit 26a7ca9a ("iwlwifi: refactor EEPROM
reading/parsing") adding a new parameter, while commit
d2c8b15d ("iwlwifi: use correct supported firmware
for 6035 and 6000g2") added a new device structure we
need to add the parameter to the new device structure
to make 6035 device work.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

For AGG queues, we must match between the WiFi sequence
number and the TFD number. This is a HW (SCD) requirement.

This is a take two of my

    iwlwifi: add debug in Tx path in AGG flow

    This will allow us to catch bad cases in which the packets aren't in
    the right place on the ring.

which disappeared during code move.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In fragmentation we don't update the write pointer of the
HW immediately. So we shouldn't modify the timer in that
case.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

CMD_SYNC is zero so the if (cmd->flags & CMD_SYNC) is never true and we
never check the assertion.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Since the queue gets stuck from time to time, we are trying
to get as much information as we can when this occurs.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When the driver is built into the kernel instead of a module
when the system boots it results in a panic. The order things are built in
results in their initialization order when built into the kernel. Wifi
has to be initialized before mvm or dvm.
Reviewed-by: NDonald H Fry <donald.h.fry@intel.com>
Tested-by: NDonald H Fry <donald.h.fry@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NBrandon Misemer <brandon.misemer@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Using the driver_data area in ieee80211_tx_info which
resides in the CB overrides the info->control field.
Add a comment to prevent mistakes.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This locking isn't needed. The only locking we need is when
we access prph registers but there is already a separate
lock for that.
Since we haven't returned from the mac80211's
IEEE80211_AMPDU_TX_OPERATIONAL ampdu_action, we cannot
receive any Tx frame for that sta / tid while enabling the
queue.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This is not needed, we just need to tell the SCD not to use
that queue. We will reconfigure that queue when we will use
it again.

Clean up a bit the code on the way.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Print some more info from the SCD's SRAM and dump the TRB
from the FH.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Change its name to better reflect this.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This macro gets the bufsize in bytes.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Add locking to the dynamic loading code to prevent
corrupting the list if multiple device ever init at
the same time (which cannot happen for multiple PCI
devices, but could happen when different busses init
concurrently.)

Also remove a device from the list when it stops so
the list isn't left corrupted, including a fix from
Don to not crash when it was never added.
Reviewed-by: NDonald H Fry <donald.h.fry@intel.com>
Tested-by: NDonald H Fry <donald.h.fry@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NDon Fry <donald.h.fry@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Conflicts:
	MAINTAINERS
	drivers/net/wireless/iwlwifi/pcie/trans.c

14e4:432c is found on some bcm63xx devices. The device is working fine
with b43.
Reported-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: NJonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

MSI is enabled by default for most of the 4th generation
chips. Add this for AR9462 - this fixes PowerSave operation,
the chip was not entering Network-Sleep mode earlier.
With proper powering down of the MAC now, power consumption
in associated state is reduced considerably.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently 4 channels are scanned per scan command. if scan request
is issued by user during Tx traffic, radio will be out of channel
for "4 * per_chan_scan_time" for each scan command and will not be
able to receive Rx packets. This adds delay in data traffic. We can
minimize it by reducing number of channels scanned per scan command
in this scenario.

We can not always scan 1 channel per scan command due to limitation
of number of command buffers. So we add code to decide number of
channels scanned per scan command in associated state.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If scan operation is started when Tx traffic is already running,
driver locks Tx queue until it gets completed. With this logic
there is a delay for Tx packets.

This patch implements new approach to give Tx path higher priority
in this case. Driver internally sends multiple synchronous scan
commands to firmware when scan is requested by user. Now we will
make sure that Tx queue is empty everytime before sending next scan
command. If Tx queue isn't empty scan command will be postponsed by
20msec. This rule will be followed until Tx queue becomes empty or
timeout of 1 second happens. In case of timeout scan operation will
be aborted.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently the scan time per channel for active scanning is set to
200ms. It takes quite a while to finsh scanning on all channels,
especially with a dual band configuration.

Change the per channel scan time settings to the following values:

passive scan: 110ms
active scan: 30ms
specific scan: 30ms

Above settings have been tested on x86 and arm platforms.
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Conflicts:
	drivers/net/wireless/iwlwifi/iwl-eeprom.c

The iwl-test flows were based on the cfg80211 testmode APIs.

To remove this coupling, the op mode (during the initialization
of the iwl_test object) is responsible to set the callbacks that
should be used by iwl-test to allocate skbs for events and replies
and to send events and replies.

The current op modes implement these callbacks based on the cfg80211
testmode APIs.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Create an object that will enacpsulate the testmode functionality
that is common to all op modes.

 * Copy definitions from dvm/dev.h
 * Copy the testmode logic from dvm/testmode.c
 * Link iwl-test object into the iwlwifi module
 * Modify DVM to use iwl-test object
Reviewed-by: NAmit Beka <amit.beka@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

  CC      drivers/net/wireless/ti/wl18xx/main.o
drivers/net/wireless/ti/wl18xx/main.c: In function ‘wl18xx_conf_init’:
drivers/net/wireless/ti/wl18xx/main.c:1024:3: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat]
drivers/net/wireless/ti/wl18xx/main.c:1024:3: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘size_t’ [-Wformat]
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

commit 24398e39
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Wed Mar 28 10:58:36 2012 +0200

    mac80211: set HT channel before association

removed IEEE80211_CONF_CHANGE_CHANNEL argument from ieee80211_hw_config,
which is required by iwl4965 driver, otherwise that driver does not
configure channel properly and is not able to associate.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

llcp_sock_getname() might get called before the LLCP socket was created.
This condition isn't checked, and llcp_sock_getname will simply deref a
NULL ptr in that case.

This exists starting with d646960f ("NFC: Initial LLCP support").
Signed-off-by: NSasha Levin <levinsasha928@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>