Some of them are BCM4706 specific AFAWK. Most of them was confirmed on
Netgear WNDR450.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: John 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: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

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

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John 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: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John 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: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: John 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: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John 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: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John 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: Eyal Shapira <eyal@wizery.com>
Signed-off-by: Luciano 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: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Eyal Shapira <eyal@wizery.com>
Signed-off-by: Luciano 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: Eyal Shapira <eyal@wizery.com>
Signed-off-by: Luciano 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: Luciano 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: Luciano 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: Johannes Berg <johannes.berg@intel.com>

Remove the unused function is_ieee80211_device().
Signed-off-by: Johannes 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: Thomas Pedersen <c_tpeder@qca.qualcomm.com>
Signed-off-by: Johannes 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: Johannes 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: Johannes Berg <johannes.berg@intel.com>

This file will contain more soon, so
rename it to just trace.
Signed-off-by: Johannes 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: Johannes 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: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano 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: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano 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: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano 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: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano 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: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano 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: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano 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: Arkady Miasnikov <a-miasnikov@ti.com>
Signed-off-by: Luciano 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: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John 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: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John 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: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John 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: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This patch fixes problem detected in linux-next build for powerpc
allyesconfig. The error message below is no longer observed:

  CC      drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.o
drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c: In function 'brcmf_sdio_dump_console':
drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c:3085: error: implicit declaration of function 'vzalloc'
drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c:3085: warning: assignment makes pointer from integer without a cast
drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c:3113: error: implicit declaration of function 'vfree'
make[2]: *** [drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.o] Error 1
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

FW will not explicitly notify about host sleep activation to the
host for USB and PCIe chipsets. Hence host should generate Host
Sleep Activated event as soon as Host Sleep parameters are
configured to FW successfully.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This is a flaw in recently implemented logic to handle Tx traffic
and scan operation simultaneously. We missed to wakeup main thread
to handle Tx traffic if scan is delayed/aborted.

For some cards (SD8797, for example), firmware will send SLEEP event
if there is no activity for 50msec. While handling the SLEEP event,
main thread will be woken up and Tx packet gets sent hence. In worst
case Tx traffic will be delayed for 50msec.

For other cards, such as USB8797, firmware won't send SLEEP event.
So, Tx traffic gets stuck if no other event triggers the wakeup of
main thread.

This patch fixes above issues.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Add support for parsing WPA IE from beacon parameter of
cfg80211_ap_settings and set it to FW.

WPA/WPA2 mixed mode is supported with this patch.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Kiran Divekar <dkiran@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>