The commit "brcmfmac: introduce checkdied debugfs functionality"
also introduced a sparse warning:

..../brcmfmac/dhd_sdio.c:3147:45: sparse: cast to restricted __le32

This patch fixes this sparse warning.
Reported-by: NFengguang Wu <wfg@linux.intel.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>

BCM4334 is a dualband a/b/g/n WiFi chip support 20MHz/40MHz
channels. This patch adds support for its SDIO interface.
Reviewed-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The nvram data is preprocessed before being sent to the device
and just before sending an additional allocation was done that
assured word alignment of the data. This has moved to the
preprocessing step to reduce allocations and subsequent copying
of the nvram data.
Reviewed-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The nvram file could be parsed directly in the data buffer in the
firmware structure passed by request_firmware function. This patch
gets rid of the redundant memcpy.
Reviewed-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

txglomming alignment is a SDIO bus specific feature. It is more
appropriate to place it in SDIO bus layer instead of common layer.
Reviewed-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

txglomming is a firmware feature for sdio bus interface. For SDIO
device cores newer than revision 11, the default setting of
firmware should be used instead of disabling it from the host side.
Reviewed-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

brcmfmac need to support data command setting for dongle's bus
core. A list must be placed at brcmf_bus structure before calling
brcmf_bus_start in order to be sent by brcmf_c_preinit_dcmds.
Reviewed-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some of them are BCM4706 specific AFAWK. Most of them was confirmed on
Netgear WNDR450.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Remove the radio enable/disable stuff and fix the
transition to FULL_SLEEP mode when the device is idle.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Cancel the MCI work only when MCI is actually enabled.
Fixes this:

[96833.124051] Call Trace:
[96833.124060]  [<ffffffff810afaf8>] __lock_acquire+0x1518/0x1e40
[96833.124065]  [<ffffffff810ad126>] ? mark_held_locks+0x86/0x110
[96833.124069]  [<ffffffff810ad3ad>] ? trace_hardirqs_on+0xd/0x10
[96833.124073]  [<ffffffff814464f0>] ? _raw_spin_unlock_irq+0x30/0x70
[96833.124078]  [<ffffffff81072968>] ? wait_on_cpu_work+0x98/0xc0
[96833.124082]  [<ffffffff810b0a11>] lock_acquire+0xa1/0x150
[96833.124085]  [<ffffffff81072990>] ? wait_on_cpu_work+0xc0/0xc0
[96833.124088]  [<ffffffff81072990>] ? wait_on_cpu_work+0xc0/0xc0
[96833.124092]  [<ffffffff810729e2>] wait_on_work+0x52/0x120
[96833.124095]  [<ffffffff81072990>] ? wait_on_cpu_work+0xc0/0xc0
[96833.124099]  [<ffffffff81063b3f>] ? del_timer+0x7f/0x110
[96833.124102]  [<ffffffff81072c13>] __cancel_work_timer+0x83/0x130
[96833.124106]  [<ffffffff81072cf0>] cancel_work_sync+0x10/0x20
[96833.124113]  [<ffffffffa065b5cd>] __ath_cancel_work+0x4d/0x60 [ath9k]
[96833.124119]  [<ffffffffa065cf28>] ath9k_config+0x458/0x680 [ath9k]
[96833.124125]  [<ffffffffa065dd1e>] ? ath9k_flush+0x6e/0x1d0 [ath9k]
[96833.124129]  [<ffffffff8144394d>] ? __mutex_unlock_slowpath+0x10d/0x190
[96833.124146]  [<ffffffffa056c7b5>] ieee80211_hw_config+0x135/0x2a0 [mac80211]
[96833.124163]  [<ffffffffa057ebbb>] ieee80211_do_open+0x67b/0xc50 [mac80211]
[96833.124178]  [<ffffffffa057f1fd>] ieee80211_open+0x6d/0x80 [mac80211]
[96833.124183]  [<ffffffff8137a44f>] __dev_open+0x9f/0xf0
[96833.124187]  [<ffffffff8137a701>] __dev_change_flags+0xa1/0x180
[96833.124190]  [<ffffffff8137a898>] dev_change_flags+0x28/0x70
[96833.124195]  [<ffffffff813e1179>] devinet_ioctl+0x659/0x780
[96833.124199]  [<ffffffff8137aea0>] ? dev_ioctl+0x210/0x6d0
[96833.124203]  [<ffffffff813e1db5>] inet_ioctl+0x75/0x90
[96833.124208]  [<ffffffff8135e0e0>] sock_do_ioctl+0x30/0x70
[96833.124211]  [<ffffffff8135e3dd>] sock_ioctl+0x7d/0x2c0
[96833.124218]  [<ffffffff81193c39>] do_vfs_ioctl+0x99/0x580
[96833.124222]  [<ffffffff81447415>] ? sysret_check+0x22/0x5d
[96833.124226]  [<ffffffff811941b9>] sys_ioctl+0x99/0xa0
[96833.124230]  [<ffffffff814473e9>] system_call_fastpath+0x16/0x1b
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

mac80211 adds stations in HT IBSS as soon as a frame comes by,
even if the HT capabilities are not known yet (they are often
received later, e.g. in beacons). So far, ampdu factor/density
are only calculated when the station is initially added.

This patch changes this to update ampdu factor/density settings
when starting a blockack session.

Using this patch, we had performance boosts from 60 to 150 MBit/s
between two 2x2 Atheros devices in 5 GHz HT IBSS mode.
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The command "make includecheck" yields the following for the rtlwifi tree:

/home/finger/linux-2.6/drivers/net/wireless/rtlwifi/rtl8192se/sw.c: ../pci.h is included more than once.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The PCI-based drivers can generate the following warning:

[ 9497.776350] ------------[ cut here ]------------
[ 9497.776366] WARNING: at kernel/softirq.c:159 local_bh_enable_ip+0x7a/0xa0()
[ 9497.776370] Hardware name: 05794NC
[ 9497.776597] Pid: 6413, comm: hostapd Not tainted 3.3.0-4.fc16.x86_64 #1
[ 9497.776601] Call Trace:
[ 9497.776612]  [<ffffffff81057b1f>] warn_slowpath_common+0x7f/0xc0
[ 9497.776633]  [<ffffffffa034a099>] ? rtl_pci_reset_trx_ring+0x199/0x230
[rtlwifi]
[ 9497.776640]  [<ffffffff81057b7a>] warn_slowpath_null+0x1a/0x20
[ 9497.776646]  [<ffffffff8105f06a>] local_bh_enable_ip+0x7a/0xa0
[ 9497.776654]  [<ffffffff815f3ef6>] _raw_spin_unlock_bh+0x16/0x20
[ 9497.776671]  [<ffffffffa03e50de>] destroy_conntrack+0x9e/0x120
[nf_conntrack]
[ 9497.776681]  [<ffffffff81511847>] nf_conntrack_destroy+0x17/0x20
[ 9497.776689]  [<ffffffff814d9c85>] skb_release_head_state+0xe5/0x120
[ 9497.776695]  [<ffffffff814d98b6>] __kfree_skb+0x16/0xa0
[ 9497.776700]  [<ffffffff814d9a35>] kfree_skb+0x45/0xc0
[ 9497.776717]  [<ffffffffa034a099>] rtl_pci_reset_trx_ring+0x199/0x230
[rtlwifi]
[ 9497.776734]  [<ffffffffa034a155>] rtl_pci_start+0x25/0x1d0 [rtlwifi]
[ 9497.776750]  [<ffffffffa03440b5>] rtl_op_start+0x55/0x90 [rtlwifi]
[ 9497.776785]  [<ffffffffa02c4956>] ieee80211_do_open+0x296/0xa10 [mac80211]
[ 9497.776794]  [<ffffffff815f7ddd>] ? notifier_call_chain+0x4d/0x70
[ 9497.776828]  [<ffffffffa02c513d>] ieee80211_open+0x6d/0x80 [mac80211]
[ 9497.776836]  [<ffffffff814e8b3f>] __dev_open+0x8f/0xe0
[ 9497.776842]  [<ffffffff814e8de1>] __dev_change_flags+0xa1/0x180
[ 9497.776847]  [<ffffffff814e8f78>] dev_change_flags+0x28/0x70
[ 9497.776856]  [<ffffffff8154e99d>] devinet_ioctl+0x61d/0x7b0
[ 9497.776863]  [<ffffffff8154ef55>] inet_ioctl+0x75/0x90
[ 9497.776870]  [<ffffffff814cdd50>] sock_do_ioctl+0x30/0x70
[ 9497.776876]  [<ffffffff814cee09>] sock_ioctl+0x79/0x2f0
[ 9497.776885]  [<ffffffff81193498>] do_vfs_ioctl+0x98/0x550
[ 9497.776891]  [<ffffffff811939e1>] sys_ioctl+0x91/0xa0
[ 9497.776897]  [<ffffffff815fc029>] system_call_fastpath+0x16/0x1b
[ 9497.776902] ---[ end trace 22886c442489082d ]---

The cause is due to calling kfree_skb() with interrupts disabled.

This bug is discussed in https://bugzilla.redhat.com/show_bug.cgi?id=797709.

Reported-and-Tested by: Ivan Ivanovich <iivanich@gmail.com>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

As recovery queuing can now occur from multiple code paths
it's convenient to know what triggered it in all cases
other than an intended recovery which is part of the
switch between single role to multi role.
Signed-off-by: NEyal Shapira <eyal@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Following the addition of propagating errors from the bus ops
there's a need to distinguish between bus errors (including timeout)
and a legitimate timeout occuring in cmd_wait_for_event_or_timeout.
In case of real bus errors we need to queue recovery even in cases
where a timeout on a response from the FW to a command is acceptable.
Reported-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NEyal Shapira <eyal@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

commit 14bba17b "wl12xx: Propagate errors from wl1271_raw_write32"
breaks down TX in certain scenarios. wl1271_irq_locked() propagates
errors from wl1271_tx_work_locked however it may return -EBUSY
when the FW queues are full which is a legitimate case and not a
a real error. In this case a recovery is triggered by wl1271_irq
and this keeps repeating itself so TX is completely broken.
Fix it by avoiding propagating return values as errors even if they
aren't. Only bus (SDIO or SPI) ops failures would be progagated
as only these should trigger recovery.
Signed-off-by: NEyal Shapira <eyal@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

We need to release the IRQ if hw_info() or identify_chip() fails.  And
we need unregister the HW with mac80211 if there are any failures
after it's registered.
Signed-off-by: NLuciano Coelho <coelho@ti.com>

The new PG2 version of the chip has a few differences in terms of FW
API if compared to PG1.  PG1 is just a sample that shouldn't be used
in real life, so to avoid having to handle both separately, mark the
PG1 version as deprecated and bail out during probe.
Signed-off-by: NLuciano Coelho <coelho@ti.com>

ieee80211_check_concurrent_iface() need not use the
netdev. Remove the use of the netdev here to prepare
the function for P2P device addition.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Remove the unused function is_ieee80211_device().
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Support configuring an RSSI threshold in dBm (s32) when requesting
scheduled scan, below which a BSS won't be reported by the cfg80211
driver.
Signed-off-by: NThomas Pedersen <c_tpeder@qca.qualcomm.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The code is fine in both cases as-is, but we can
write it slightly differently to fix smatch/sparse
complaints:
 * compare the skb pointer (which we use as a cookie)
   by casting the skb to unsigned long rather than the
   cookie to a pointer (fixes "different address spaces")
 * when transmitting, data->channel must be assigned,
   don't check it (fixes "dereferenced before check")
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

It can be very useful to have all debug messages
available when debugging, but hard to correlate
between different sources, so add a trace event
for all mac80211 debug messages.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This file will contain more soon, so
rename it to just trace.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

There are a few things that make the logging and
debugging in mac80211 less useful than it should
be right now:
 * a lot of messages should be pr_info, not pr_debug
 * wholesale use of pr_debug makes it require *both*
   Kconfig and dynamic configuration
 * there are still a lot of ifdefs
 * the style is very inconsistent, sometimes the
   sdata->name is printed in front

Clean up everything, introducing new macros and
separating out the station MLME debugging into
a new Kconfig symbol.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Take the mutex early in the resume handler and use the locked version of
the IRQ routine. This ensures any recoveries queued will only take place
after resume has fully completed.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Separate the threaded IRQ handling routine into two functions.
The outer function takes the mutex and calls recovery on errors. It also
performs a Tx-path optimization to avoid redundant works.

The inner function is simplified - all calls to recovery are removed and
it assumes the lock is taken. The locked variant will be reused elsewhere.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Propagate some missing return values for Rx-filter related functions.
This and makes sure we always fail the suspend in case of SDIO errors.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

If an error is detected after mac80211 is already suspended, the recovery
work will not be queued. This will leave the driver in a bad state on
resume.

Detect this in the resume op and re-queue a recovery.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Set a flag and after the first read/write failure is encountered.
This flag will disallow further SDIO read/writes until op_stop() is
executed, which will clear all flags.

This prevents further errors from occurring, since one error usually
indicates that IO operations won't work anymore until the chip is
rebooted.  By blocking more calls, we avoid extra timeouts and having
to wait for them to occur.

[Added second paragraph explaining why the change is needed. -- Luca]
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

We wish to postpone suspend if recovery is pending. This will make sure
the FW is in a good state and perform wowlan wakeup.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

Applications running in the user space needs access to the
memory of the chip. Examples of such access
- read/write global variables
- access to firmware log
- dump memory after firmware panic event

Arbitrary 4-bytes aligned location can be accessed by
read/write file wlcore/mem

[Check return value of wlcore_raw_read/write and wlcore_set_partition
calls as required by the recent IO changes. -- Luca]
Signed-off-by: NArkady Miasnikov <a-miasnikov@ti.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

When running in AP mode, the driver reports all deletions from CAM in
a cryptic manner that makes users think it is an error. change so that
the condition is only reported at higher-levels of debugging.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

drivers/net/wireless/ath/ath9k/ar9003_phy.c:211
ar9003_hw_spur_mitigate_mrc_cck() error: potential NULL dereference
'spur_fbin_ptr'.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Rename mrcCCKOff for better code readability and also fixes
the smatch warning.

drivers/net/wireless/ath/ath9k/ar9003_phy.c:982
	ar9003_hw_ani_control() Error invalid range 1 to 0.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In the function brcms_c_regd_init() the channels are validated
against the device capabilities. This is done for both 2.4G and
5G band, but there are devices that are 2.4G only, ie. BCM4313.
For that device this leads to a NULL dereference. This patch adds
a check in brcms_c_regd_init() to fix this.

Issue introduced in wireless-next tree by following commit:
cf03c5da brcm80211: smac: inform mac80211 of the X2 regulatory domain

Cc: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>