AR9003 chips read tx status from ring buffer whose max number of
status descriptor is mininal compared to max number of tx buffers.
On a stress condition, it can be easily overflown which might cause
false tx hung detection. Though increasing number of max status
descriptors consumes more memory, it helps to avoid false positive
chip resets.

Cc: Paul Stewart <pstew@google.com>
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Patch fix firmware error on "iw dev wlan0 scan passive" for
hardware scanning (with disable_hw_scan=0 module parameter).

 iwl3945 0000:03:00.0: Microcode SW error detected. Restarting 0x82000008.
 iwl3945 0000:03:00.0: Loaded firmware version: 15.32.2.9
 iwl3945 0000:03:00.0: Start IWL Error Log Dump:
 iwl3945 0000:03:00.0: Status: 0x0002A2E4, count: 1
 iwl3945 0000:03:00.0: Desc       Time       asrtPC blink2 ilink1  nmiPC   Line
 iwl3945 0000:03:00.0: SYSASSERT     (0x5) 0041263900 0x13756 0x0031C 0x00000 764
 iwl3945 0000:03:00.0: Error Reply type 0x000002FC cmd C_SCAN (0x80) seq 0x443E ser 0x00340000
 iwl3945 0000:03:00.0: Command C_SCAN failed: FW Error
 iwl3945 0000:03:00.0: Can't stop Rx DMA.

We have disable ability to change passive scanning to active on
particular channel when traffic is detected on that channel. Otherwise
firmware will report error, when we try to do passive scan on radar
channels.
Reported-and-debugged-by: NPedro Francisco <pedrogfrancisco@gmail.com>
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We have two such functions.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Remove these helpers, some are not unused at all, one can be
unrolled in place of use.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Get rid of two inline functions related and simplify a bit
rts_retry_limit calculations.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Make function static and change antenna number inline.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This save us about 20k of text size, and should have no impact on
performance as hot paths do not use much I/O.

Before:
   text	   data	    bss	    dec	    hex	filename
 108512	   1784	    168	 110464	  1af80	drivers/net/wireless/iwlegacy/iwl3945.ko
 165730	   2164	    156	 168050	  29072	drivers/net/wireless/iwlegacy/iwl4965.ko
  91942	    328	     48	  92318	  1689e	drivers/net/wireless/iwlegacy/iwlegacy.ko

After:
   text	   data	    bss	    dec	    hex	filename
  95556	   1784	    168	  97508	  17ce4	drivers/net/wireless/iwlegacy/iwl3945.ko
 154853	   2164	    156	 157173	  265f5	drivers/net/wireless/iwlegacy/iwl4965.ko
  91634	    328	     48	  92010	  1676a	drivers/net/wireless/iwlegacy/iwlegacy.ko
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We use "rate_index" like this:
	rate = iwl3945_rates[rate_index].plcp;
The iwl3945_rates[] array has IWL_RATE_COUNT_3945 elements so the
limit here is off by one.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

I forgot to remove this file before.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is just a cosmetical fix since we only return survey data for the
active channel but it allows iw to show that the survey data is
for the currently used channel.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch addresses a bug in the dma worker code that keeps draining
packets even when the hardware queues are full. In such cases packets
can not be passed down to the device and are erroneusly dropped by the
code. It is based on commit bad69194,
which fixes the same problem in b43.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Specs were updated, now we match wl according to MMIO dumps.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This fixes this sparse warning:

  CHECK   drivers/net/wireless/ath/ath9k/mci.c
drivers/net/wireless/ath/ath9k/mci.c:23:4: warning: symbol 'ath_mci_duty_cycle' was not declared. Should it be static?
Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Replace dma_alloc_coherent()+memset() with the new dma_zalloc_coherent()
Signed-off-by: NDjalal Harouni <tixxdz@opendz.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This fixes this sparse complaint:

make C=2 CF="-D__CHECK_ENDIAN__" M=drivers/net/wireless/ath/

  CHECK   drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c:3544:21: warning: incorrect type in assignment (different base types)
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c:3544:21:    expected restricted __le32 [usertype] val
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c:3544:21:    got restricted __le16 [usertype] switchcomspdt
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c:3546:21: warning: incorrect type in assignment (different base types)
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c:3546:21:    expected restricted __le32 [usertype] val
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c:3546:21:    got restricted __le16 [usertype] switchcomspdt

The eep->modalHeader5G.switchcomspdt is a le16 and we return u16,
so just return le16_to_cpu().

Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Just skip the sparse checks on tracing.

  CHECK   drivers/net/wireless/ath/ath5k/base.c
include/trace/../../drivers/net/wireless/ath/ath5k/trace.h:19:1: error: incompatible types for operation (<)
include/trace/../../drivers/net/wireless/ath/ath5k/trace.h:19:1:    left side has type struct ath5k_hw *<noident>
include/trace/../../drivers/net/wireless/ath/ath5k/trace.h:19:1:    right side has type int
include/trace/../../drivers/net/wireless/ath/ath5k/trace.h:37:1: error: incompatible types for operation (<)
include/trace/../../drivers/net/wireless/ath/ath5k/trace.h:37:1:    left side has type struct ath5k_hw *<noident>
include/trace/../../drivers/net/wireless/ath/ath5k/trace.h:37:1:    right side has type int
include/trace/../../drivers/net/wireless/ath/ath5k/trace.h:63:1: error: incompatible types for operation (<)
include/trace/../../drivers/net/wireless/ath/ath5k/trace.h:63:1:    left side has type struct ath5k_hw *<noident>
include/trace/../../drivers/net/wireless/ath/ath5k/trace.h:63:1:    right side has type int
/home/mcgrof/wireless-testing/arch/x86/include/asm/jump_label.h:16:9: error: bad asm output
/home/mcgrof/wireless-testing/arch/x86/include/asm/jump_label.h:16:9: error: bad asm output
/home/mcgrof/wireless-testing/arch/x86/include/asm/jump_label.h:16:9: error: bad asm output
/home/mcgrof/wireless-testing/arch/x86/include/asm/jump_label.h:16:9: error: bad asm output
  CC [M]  drivers/net/wireless/ath/ath5k/base.o
Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This fixes this rant from sparse:

  CHECK   drivers/net/wireless/ath/ath9k/xmit.c
drivers/net/wireless/ath/ath9k/xmit.c:107:13: warning: context imbalance in 'ath_txq_lock' - wrong count at exit
drivers/net/wireless/ath/ath9k/xmit.c:112:13: warning: context imbalance in 'ath_txq_unlock' - unexpected unlock
drivers/net/wireless/ath/ath9k/xmit.c:123:30: warning: context imbalance in 'ath_txq_unlock_complete' - unexpected unlock
  CC [M]  drivers/net/wireless/ath/ath9k/xmit.
Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This fixes these sparse warnings:

  CHECK   drivers/net/wireless/ath/ath9k/ar9003_rtt.c
drivers/net/wireless/ath/ath9k/ar9003_rtt.c:36:6: warning: symbol 'ar9003_hw_rtt_enable' was not declared. Should it be static?
drivers/net/wireless/ath/ath9k/ar9003_rtt.c:41:6: warning: symbol 'ar9003_hw_rtt_disable' was not declared. Should it be static?
drivers/net/wireless/ath/ath9k/ar9003_rtt.c:46:6: warning: symbol 'ar9003_hw_rtt_set_mask' was not declared. Should it be static?
drivers/net/wireless/ath/ath9k/ar9003_rtt.c:52:6: warning: symbol 'ar9003_hw_rtt_force_restore' was not declared. Should it be static?
drivers/net/wireless/ath/ath9k/ar9003_rtt.c:102:6: warning: symbol 'ar9003_hw_rtt_load_hist' was not declared. Should it be static?
drivers/net/wireless/ath/ath9k/ar9003_rtt.c:135:6: warning: symbol 'ar9003_hw_rtt_fill_hist' was not declared. Should it be static?
drivers/net/wireless/ath/ath9k/ar9003_rtt.c:143:6: warning: symbol 'ar9003_hw_rtt_clear_hist' was not declared. Should it be stati
Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add another vendor specific ID for BCM20702A0.

output of usb-devices:
T: Bus=06 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0a5c ProdID=21e3 Rev=01.12
S: Manufacturer=Broadcom Corp
S: Product=BCM20702A0
S: SerialNumber=9439E5CBF66C
C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
Signed-off-by: NWen-chien Jesse Sung <jesse.sung@canonical.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>

Currently due to following issues in the code even if device is
configured in B only, G only or BG mode using iw bitrates command,
ibss is getting created in BGN mode.

1) mwifiex_channels_to_cfg80211_channel_type() routine gives channel
type as NL80211_CHAN_HT20 for non-HT channel as well, because driver
doesn't store HT information provided by stack for the channel.
This issue is fixed by maintaining channel type information in
'adapter->channel_type'.
2) Band configuration is unnecessarily overwritten with BGN/AN while
setting channel.

This patch makes sure that "adapter->config_bands" correctly gets
modified while setting channel.
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>

Replace driver specific macros with the corresponding
IEEE80211_HT_PARAM_CHA_SEC_* macros defined in ieee80211.h.
Also, rename 'adapter->chan_offset' to 'adapter->sec_chan_offset'
for consistency.
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>

struct mwifiex_ds_band_cfg and mwifiex_set_radio_band_cfg() routine
are unnecessary. It can be done with simple equivalant code.
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>

Please NACK nasty patches.

Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When stack calls ampdu_action with action = IEEE80211_AMPDU_TX_STOP
for a stream that has already been removed from the driver, call
ieee80211_tx_ba_stop_irqsafe to clear the stream in the stack.
Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: NNishant Sarmukadam <nishants@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Joe changed ath_dbg() to simpify code but while his patch was
being merged dfs.c was born and as such did not get the change
Joe envisioned. This fixes that. Test compiled with:

 make allmodconfig

Cc: Joe Perches <joe@perches.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: John W. Linville <linville@tuxdriver.com>
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The ICT code erroneously uses PAGE_SIZE. The bug
is that PAGE_SIZE isn't necessarily 4096, so on
such platforms this code will not work correctly
as we'll try to attempt to read an index in the
table that the device never wrote, it always has
4096-byte pages.

Additionally, the manual alignment code here is
unnecessary -- Documentation/DMA-API-HOWTO.txt
states:
  The cpu return address and the DMA bus master address are both
  guaranteed to be aligned to the smallest PAGE_SIZE order which
  is greater than or equal to the requested size.  This invariant
  exists (for example) to guarantee that if you allocate a chunk
  which is smaller than or equal to 64 kilobytes, the extent of the
  buffer you receive will not cross a 64K boundary.

Just use appropriate new constants and get rid of
the alignment code.

Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Just another USB identifier.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The libertas scan thread expects priv->scan_req to be non-NULL.  In theory,
it should always be set.  In practice, we've seen the following oops:

[ 8363.067444] Unable to handle kernel NULL pointer dereference at virtual address 00000004
[ 8363.067490] pgd = c0004000
[ 8363.078393] [00000004] *pgd=00000000
[ 8363.086711] Internal error: Oops: 17 [#1] PREEMPT
[ 8363.091375] Modules linked in: fuse libertas_sdio libertas psmouse mousedev ov7670 mmp_camera joydev videobuf2_core videobuf2_dma_sg videobuf2_memops [last unloaded: scsi_wait_scan]
[ 8363.107490] CPU: 0    Not tainted  (3.0.0-gf7ccc69 #671)
[ 8363.112799] PC is at lbs_scan_worker+0x108/0x5a4 [libertas]
[ 8363.118326] LR is at 0x0
[ 8363.120836] pc : [<bf03a854>]    lr : [<00000000>]    psr: 60000113
[ 8363.120845] sp : ee66bf48  ip : 00000000  fp : 00000000
[ 8363.120845] r10: ee2c2088  r9 : c04e2efc  r8 : eef97005
[ 8363.132231] r7 : eee0716f  r6 : ee2c02c0  r5 : ee2c2088  r4 : eee07160
[ 8363.137419] r3 : 00000000  r2 : a0000113  r1 : 00000001  r0 : eee07160
[ 8363.143896] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[ 8363.157630] Control: 10c5387d  Table: 2e754019  DAC: 00000015
[ 8363.163334] Process kworker/u:1 (pid: 25, stack limit = 0xee66a2f8)

While I've not found a smoking gun, there are two places that raised red flags
for me.  The first is in _internal_start_scan, when we queue up a scan; we
first queue the worker, and then set priv->scan_req.  There's theoretically
a 50mS delay which should be plenty, but doing things that way just seems
racy (and not in the good way).

The second is in the scan worker thread itself.  Depending on the state of
priv->scan_channel, we cancel pending scan runs and then requeue a run in
300mS.  We then send the scan command down to the hardware, sleep, and if
we get scan results for all the desired channels, we set priv->scan_req to
NULL.  However, it that's happened in less than 300mS, what happens with
the pending scan run?

This patch addresses both of those concerns.  With the patch applied, we
have not seen the oops in the past two weeks.
Signed-off-by: NAndres Salomon <dilinger@queued.net>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

DFS_DEBUG_H is very generic, instead use something more specific
to ath9k such as ATH9K_DFS_DEBUG_H.
Reported-by: NJulian Calaby <julian.calaby@gmail.com>
Signed-off-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

For high-speed/super-speed isochronous endpoints, the bInterval
value is used as exponent, 2^(bInterval-1). Luckily we have
usb_fill_int_urb() function that handles it correctly. So we just
call this function to fill in the RX URB.

Cc: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>

stop sched scan isn't an immediate operation
and we need to wait for PERIODIC_SCAN_COMPLETE_EVENT_ID
after sending a stop before changing internal state
and notifying upper layers.
Not doing this caused problems when canceling an existing sched
scan and immediately requesting to start a new one
with a different configuration as the FW was still
in the middle of the previous sched scan.
Signed-off-by: NEyal Shapira <eyal@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>

DFS channels weren't scanned properly because
min/max_duration weren't set for these channels
even though they're required by the FW.
The change sets passive_duration and min/max_duration
for all channels as the FW uses the correct parameters
according to the channel type.
Signed-off-by: NEyal Shapira <eyal@wizery.com>
Signed-off-by: NLuciano Coelho <coelho@ti.com>