When the TX status handler failed to clear the queue
in rt2x00usb_watchdog_tx_dma() we shouldn't use a failsave
to use the rt2x00usb txdone handler.

If a driver has overriden the txdone handler it must make
sure the txdone handler is capable of cleaning up the queue itself.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Rename rt2x00queue_timeout to rt2x00queue_status_timeout to
better describe what is actually timing out (note that
we already have a rt2x00queue_dma_timeout).
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When rt2x00 is compiled with debugging but frame dumping is currently
not active we can avoid the call to do_gettimeofday. Furthermore,
frame dumping is not the default case, mark it as unlikely.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The tx descriptor values qid, cw_min, cw_max and aifs are directly
accessible through the tx entry struct. So there's no need to copy
them into the tx descriptor and passing them to the indiviual drivers.
Instead we can just get the correct value from the tx entry.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

At least some devices need such a long time to inititalize WPDMA. This
only increases the maximum wait time and shouldn't affect devices that
have been working before.
Reported-by: NJoshua Smith <jesmith@kaon.com>
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

All rt2x00 devices used the same Tx and Rx ring size (24 entries) till
now. Newer devices (like rt2800) can however make use of a larger TX and
RX ring due to 11n capabilities (AMPDUs of size 64 for example).

Hence, bring rt2x00 in sync with the legacy drivers and use the same TX
and RX ring sizes. Also remove the global defines RX_ENTRIES, TX_ENTRIES,
BEACON_ENTRIES and ATIM_ENTRIES and use per driver values.

That is 24 entries for rt2400pci, 32 entries for rt2500pci, rt2500usb,
rt61pci and rt73usb and 128 (RX) and 64 (TX) for rt2800pci and rt2800usb.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Remove the magic value initialisation of the TXOP_CTRL_CFG register by
defining its fields and using them during intialisation. The field
RESERVED_TRUN_EN is referred to as reserved, however it is set to 1 by
the legacy drivers. Hence, do the same.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The current ath9k tx queue handling code showed a few issues that could
lead to locking issues, tx stalls due to stopped queues, and maybe even
DMA issues.

The main source of these issues is that in some places the queue is
selected via skb queue mapping in places where this mapping may no
longer be valid. One such place is when data frames are transmitted via
the CAB queue (for powersave buffered frames). This is made even worse
by a lookup WMM AC values from the assigned tx queue (which is
undefined for the CAB queue).

This messed up the pending frame counting, which in turn caused issues
with queues getting stopped, but not woken again.

To fix these issues, this patch removes an unnecessary abstraction
separating a driver internal queue number from the skb queue number
(not to be confused with the hardware queue number).

It seems that this abstraction may have been necessary because of tx
queue preinitialization from the initvals. This patch avoids breakage
here by pushing the software <-> hardware queue mapping to the function
that assigns the tx queues and redefining the WMM AC definitions to
match the numbers used by mac80211 (also affects ath9k_htc).

To ensure consistency wrt. pending frame count tracking, these counters
are moved to the ath_txq struct, updated with the txq lock held, but
only where the tx queue selected by the skb queue map actually matches
the tx queue used by the driver for the frame.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Reported-by: NBjörn Smedman <bjorn.smedman@venatech.se>
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>

The Mandriva patch seems to stem from 2.6.14, so much for their
upstreaming effort.

Didn't find another Linux reference of it, just an omnious
"USB\VID_1044&PID_8004" from GigabyteZD1201U.INF for
Gigabyte GN-WLBZ101 802.11b USB Adapter, which matches the
Mandriva patch comment.

Aboves file also lists an "USB\VID_1044&PID_8006", which I have
kept appart as this "Gigabyte GN-WBZB-M 802.11b USB Adapter"
didn't show up in googling.
Signed-off-by: Nmaximilian attems <max@stro.at>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

"These USB ID came from Palnex <http://www.planex.co.jp/>
Worked fine." says Mandriva patch for their 2.6.32 and earlier.

Web has evidence for both id's to work, so just add them upstream:
http://www.mail-archive.com/zd1211-devs@lists.sourceforge.net/msg00507.html
http://ubuntuforums.org/showthread.php?t=473046Signed-off-by: NGo Taniguchi <go@turbolinux.co.jp>
Signed-off-by: Nmaximilian attems <max@stro.at>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Current 8187B initialization misses anaparam registers restore after
8187 reset. This causes ANAPARAM register to stay zeroed out (ANAPARAM2
kept its value on my tests). To avoid this, call rtl8187_set_anaparam
right after chip reset (to be on the safe side, as it makes sure we
restore all ANAPARAM registers).
Signed-off-by: NHerton Ronaldo Krzesinski <herton@mandriva.com.br>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: seno <senada@t-online.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Usually you set RTL818X_CONFIG3_ANAPARAM_WRITE when you are going to
change/write ANAPARAM registers. But in current initialization of
RTL8187B there is a place where ANAPARAM_WRITE bit is set without any
ANAPARAM register being written, without reason, so remove it.
Signed-off-by: NHerton Ronaldo Krzesinski <herton@mandriva.com.br>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: seno <senada@t-online.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There are repeated calls for anaparam on/off sequence in the code.
Consolidate the common code in rtl8187_set_anaparam and use it where
needed.
Signed-off-by: NHerton Ronaldo Krzesinski <herton@mandriva.com.br>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The GNTSel bit should only concern pci devices by looking at RTL8180
spec, which is not the case of 8187B. Also testing shows that trying to
set this bit fails, a subsequent read from the register after trying to
set it shows that the bit isn't set, seems the hardware ignores it,
which makes sense. This setting was a left over from Realtek sources.
Signed-off-by: NHerton Ronaldo Krzesinski <herton@mandriva.com.br>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On 8187B start, comment about pll reset, and move it out of ANAPARAM
write sequence, so that code is more readable.
Signed-off-by: NHerton Ronaldo Krzesinski <herton@mandriva.com.br>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The table with misc register initialization was setting it, and later
on we would set it again with a explicity call to rtl818x_iowrite16_idx.

Remove duplicate initialization from the register table.
Signed-off-by: NHerton Ronaldo Krzesinski <herton@mandriva.com.br>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We were using wrong address for BRSR (Basic Rate Set Register) while
initializing its value, comparing with Realtek sources, for 8187B case.

Also, the same register is initialized in rtl8187b_reg_table, so remove
the duplicate initialization from the table.
Signed-off-by: NHerton Ronaldo Krzesinski <herton@mandriva.com.br>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On 8187B path, we set a initial value for beacon interval and atim
window on initialization. But this isn't needed, since same setup is
done on rtl8187_config.
Signed-off-by: NHerton Ronaldo Krzesinski <herton@mandriva.com.br>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This removes redundant write to Auto Rate Fallback Register on RTL8187B.
The same value was being written twice in the same function. Avoid this
removing the duplicate initialization on rtl8187b_reg_table, and also
add comment for this write (information from Realtek source).
Signed-off-by: NHerton Ronaldo Krzesinski <herton@mandriva.com.br>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

AP firmware uses xmitcontrol to differentiate between AMPDU
and non-AMPDU frames. As the support for AMPDU is not yet
added, set xmitcontrol to non-AMPDU for all tx frames for AP
firmware. This field will be set to indicate ampdu/non-ampdu
frames when tx AMPDU support is added.
Signed-off-by: NPradeep Nemavat <pnemavat@marvell.com>
Signed-off-by: NBrian Cavagnolo <brian@cozybit.com>
Acked-by: NLennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Previously, the beacon rate was fixed to either:
 * 1Mb/s [2.4GHz band]
 * 6Mb/s [5GHz band]

This limitation has been addressed and now the
beacon rate is selected by ieee80211_tx_info's
rate control info, almost like any ordinary
data frame.
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes a possible lengthy stall if the device
is operating as an experimental 11n AP and an STA
[during heavy txrx action] suddenly signalized to go
off-channel (old NetworkManager), or (sleep - which is
unlikely, because then it wouldn't be *active* at all!?).

Because the driver has to manage the BA Window, the
sudden PSM transition can leave active uplink BA
sessions to the STA in a bad state and a proper
cleanup is needed.
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

RX Stress tests of unidirectional bulk traffic with
bitrates of up to 220Mbit/s have revealed that the
fatal-event recovery logic [which was solely triggered
by an out-of-rx-buffer situation] is too aggressive.

The new method now "pings" the device and then
decides - based on the response - whenever
a restart is needed or not.
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch changes the initial aMPDU density and
factor settings to match those of Otus.
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch imports all shared header changes
from carl9170fw.git.

 * add some strategic __aligned(4).
   This allows the compiler generate optimized code for
   architectures which can't access (unaligned/packed)
   data efficiently.
   ("ath9k_hw: optimize all descriptor access functions")

 * add a forgotten __CARL9170FW__ ifdef around
   a private firmware-internal struct.

 * GET_VAL macro helper
   Very useful for extracting data out of the
   bit-packed PHY registers.

 * cosmetic changes
   e.g.: _CCA_MINCCA_ to just _CCA_MIN_.

 * version bump 1.8.8.3 -> 1.9.0.
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Up to now mac80211_hwsim has been reporting an rssi of -50. This patch
improves the model slightly by returning txpower-50. This makes it
easy to stimulate tests that need to see a varying rssi.
Signed-off-by: NBlaise Gassend <blaise@willowgarage.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Clearing the per packet TX AGC for the RTL8187B device appears to
increase its overall TX power. This allows the device to associate and a
connection to be established using APs a little further away.

This is in accordance to what is done for RTL8187L devices and also what
Realtek drivers do.
Tested-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Cc: linux-wireless@vger.kernel.org
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Rogerio Luz Coelho <rogluz.news@gmail.com>
Cc: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Cc: Hin-Tak Leung <hintak.leung@gmail.com>
Cc: seno <senada@t-online.de>
Tested-by: NHerton Ronaldo Krzesinski <herton@mandriva.com.br>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

add RECOVER testmode command.
this command triggers a recovery sequence (by enqueueing a recovery_work).
Signed-off-by: NEliad Peller <eliad@wizery.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>

unmask the WL1271_ACX_INTR_WATCHDOG interrupt.
when getting it - enqueue a recovery work and bail out.
Signed-off-by: NEliad Peller <eliad@wizery.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>

refactor wl1271_debugfs by using a format&copy function, instead of
duplicating the code for each generated function.

this change reduces about 3Kb from wl1271.ko
Signed-off-by: NEliad Peller <eliad@wizery.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>

set wl->vif to the newly created interface only after the firmware booted
successfully. on the way - make the function flow more clear.
Signed-off-by: NEliad Peller <eliad@wizery.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>

Check the state of the interface on op_* function so we don't try to access
the hardware in when its off.

The mac80211 may call these in some corner cases related, for instance, to
the hardware recovery procedure. These accesses cause a kernel crash on at
least some SDIO devices, because the bus is not properly claimed in that
scenario.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>

In scan_complete_work, because the mutex is released before accessing the
scan->failed flag, it is possible for unfounded hardware recovery rounds
to be executed.

Fix this.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>

The wl1271_rx function loops through packets in an aggregated buffer. Each
packet in the buffer is handled by a call to wl1271_rx_handle_data, which will
fail if skb memory allocation fails or production mode is enabled. These
failures currently prevent the rx counters to be incremented, thus causing the
rx loop to run forever.

Fix this by ignoring error codes reported wl1271_rx_handle_data function.
This essentially means that frames will be dropped in production mode, which
is the intetion, and frames will be dropped if memory allocation fails, which
is a decent way to recover from that situation.
Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Tested-by: NTuomas Katila <ext-tuomas.2.katila@nokia.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>

wl1271_ps_elp_sleep() is void and cannot return a value.
Signed-off-by: NNicolas Kaiser <nikai@nikai.net>
Reviewed-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>

This bug was being triggered by a call to acx_rate_policies in tx_work
without calling ps_elp_wakeup first.  If we have full PSM enabled, this
happens rather often, immediately after association.
Reported-by: NTuomas Katila <ext-tuomas.2.katila@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>
Tested-by: NTuomas Katila <ext-tuomas.2.katila@nokia.com>

While scanning, it is possible that beacon and probe response frames are
received on other band than configured to the driver. In rx status
handling this has caused "Unsupported RX rate from HW" warnings. This
patch changes the wl1271_rate_to_index function to take the band of the
received frame as a parameter instead of using value configuret to
wl->band.
Signed-off-by: NTeemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
Reviewed-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>

Add 11n ability in scan, connection and using MCS rates.
The configuration is temporary due to the code incomplete and
still in testing process. That plans to be remove in the future.
Signed-off-by: NShahar Levi <shahar_levi@ti.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>

Added ACX command to the FW for 11n support.
Signed-off-by: NShahar Levi <shahar_levi@ti.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>