Not doing so, could cause imbalance in powersave count.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Choose legacy rate as the last rate of Multi Rate Retry series
if and only if the last selected rate is MCS and having higher
PER rate. The current code fills a legacy rate as last one even
though the previous rates in the series are having good PER value.
This could limit the aggregation that affects the uplink performance.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Adjust quick_drop value in the baseband AGC register to
improve RX in HT20 mode.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The structure brcmf_sdio contains a number of counters that are useful
for debugging. These were not available in user-space. This patch
exposes them in debugfs under the filename 'counters'.
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: NFranky (Zhenhui) Lin <frankyl@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch adds debugfs support to brcmfmac. It provide helper functions
to setup the debugfs folder structure for the driver, which has following
hierarchy:

<debugfs_mount>/brcmfmac/<dev_name>/

ie.: /sys/kernel/debug/brcmfmac/mmc0:0001:2/

The new source file provides functions to create and remove the two
folders and a function to retrieve the device-specific folder so files
can be created in it.
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: NFranky (Zhenhui) Lin <frankyl@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes potential NULL pointer dereference in ampdu. This
was found running smatch static code checker. Smatch warning says:

drivers/net/wireless/brcm80211/brcmsmac/ampdu.c:741 brcms_c_sendampdu()
	 warn: variable dereferenced before check 'p'
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The function brcms_set_hint() does not add any functionality
so regulatory_hint() can be called directly. The error value
has been removed from the message when regulatory_hint() fails.
Reported-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.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>

This feature has been reported to be buggy and enabled by
default. We therefore need to disable it manually.

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

When we remove a key, we put a key index which was supposed
to tell the fw that we are actually removing the key. But
instead the fw took that index as a valid index and messed
up the SRAM of the device.

This memory corruption on the device mangled the data of
the SCD. The impact on the user is that SCD queue 2 got
stuck after having removed keys.
The message is the log that was printed is:

Queue 2 stuck for 10000ms

This doesn't seem to fix the higher queues that get stuck
from time to time.

Cc: stable@vger.kernel.org [2.6.27+]
Reviewed-by: NMeenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

pc could be null if hosttype != BCMA_HOSTTYPE_PCI.
If we are on a device without a pci core this function is called with
pc = null by b43 and brcmsmac. If the host type is PCI we have a pci
core as well and pc can not be null.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

this patch fixes kernel Oops on "rmmod b43" if firmware was not loaded:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000088
IP: [<ffffffff8104e988>] drain_workqueue+0x25/0x142
PGD 153ac6067 PUD 153b82067 PMD 0
Oops: 0000 [#1] SMP
Signed-off-by: NOleksij Rempel <bug-track@fisher-privat.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>