Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The checksums of the initvals are:

initvals -f ar9003-2p2
0x00000000c2bfa7d5        ar9300_2p2_radio_postamble
0x00000000ada2b114        ar9300Modes_lowest_ob_db_tx_gain_table_2p2
0x00000000e0bc2c84        ar9300Modes_fast_clock_2p2
0x00000000056eaf74        ar9300_2p2_radio_core
0x0000000000000000        ar9300Common_rx_gain_table_merlin_2p2
0x0000000078658fb5        ar9300_2p2_mac_postamble
0x0000000023235333        ar9300_2p2_soc_postamble
0x0000000054d41904        ar9200_merlin_2p2_radio_core
0x000000008475a084        ar9300_2p2_baseband_postamble
0x000000009aaafd90        ar9300_2p2_baseband_core
0x000000003df9a326        ar9300Modes_high_power_tx_gain_table_2p2
0x000000001cfba124        ar9300Modes_high_ob_db_tx_gain_table_2p2
0x0000000011302700        ar9300Common_rx_gain_table_2p2
0x00000000a9a2b114        ar9300Modes_low_ob_db_tx_gain_table_2p2
0x00000000a9d66d40        ar9300_2p2_mac_core
0x000000001e1d0800        ar9300Common_wo_xlna_rx_gain_table_2p2
0x00000000a0c531c8        ar9300_2p2_soc_preamble
0x00000000292e2544        ar9300PciePhy_pll_on_clkreq_disable_L1_2p2
0x000000002d3e2544        ar9300PciePhy_clkreq_enable_L1_2p2
0x00000000293e2544        ar9300PciePhy_clkreq_disable_L1_2p2
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This bug was introduced by the following commit

	Author: Vasanthakumar Thiagarajan <vasanth@atheros.com>
	Date:   Thu Apr 15 17:38:46 2010 -0400

	ath9k: Remove ATH9K_TX_SW_ABORTED and introduce a bool for this purpose

Wrong buffer is checked for bf_tx_aborted field in ath_tx_num_badfrms(),
this may result in a rate scaling with wrong feedback (number
of unacked frames in this case). It is the last one in the chain
of buffers for an aggregate frame that should be checked.

Also it misses the initialization of this field in the buffer,
this may lead to a situation where we stop the sw retransmission
of failed subframes associated to this buffer.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ath_print in xmit.c should say "Reseting hardware"
instead of Resetting HAL!(since HAL is being fazed out).
dmesg shows:
[ 8660.899624] ath: Failed to stop TX DMA in 100 msec after killing last frame
[ 8660.899676] ath: Unable to stop TxDMA. Reset HAL!
Signed-off-by: NJustin P. Mattock <justinmattock@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Commit "ar9170: wait for asynchronous firmware loading"
introduced a bug, which is triggered by fatal errors
while the driver is initializing the device.

BUG: unable to handle kernel paging request at 6b6b6bf7
IP: [<c117b567>] kobject_put+0x7/0x70
*pde = 00000000
Oops: 0000 [#1] PREEMPT
last sysfs file: /sys/devices/platform/hdaps/position
Modules linked in: ar9170usb [...]

Pid: 6246, comm: firmware/ar9170 Not tainted 2.6.34-wl #54
EIP: 0060:[<c117b567>] EFLAGS: 00010206 CPU: 0
EIP is at kobject_put+0x7/0x70
EAX: 6b6b6bd7 EBX: f4d3d0e0 ECX: f5ba9124 EDX: f6af2a7c
ESI: 00000000 EDI: f4d3d0e0 EBP: 00000000 ESP: f5e98f9c
 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
Process firmware/ar9170 (pid: 6246)
Stack:
 c12532ed 00000246 f5bfaa70 f8487353 f4d3d0e0
Call Trace:
 [<c12532ed>] ? device_release_driver+0x1d/0x30
 [<f8487353>] ? ar9170_usb_firmware_failed+0x43/0x70 [ar9170usb]
 [<c125983c>] ? request_firmware_work_func+0x2c/0x70
 [<c1259810>] ? request_firmware_work_func+0x0/0x70
 [<c10413f4>] ? kthread+0x74/0x80
 [<c1041380>] ? kthread+0x0/0x80
 [<c1003136>] ? kernel_thread_helper+0x6/0x10
Code: 40 d3 f2 ff 85 c0 89 c3 74 0a ba 44 86 4c c1 e8 [...]
EIP: [<c117b567>] kobject_put+0x7/0x70 SS:ESP 0068:f5e98f9c
CR2: 000000006b6b6bf7
---[ end trace e81abb992434b410 ]---
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

With VEOL, Beacon transmission in ad-hoc does not currently work.
I believe for larger ad-hoc networks, VEOL is too unreliable, as
it can get beacon transmissions stuck during synchronization.
Use SWBA based beacon trasmission similar to AP mode instead.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Acked-by: NBenoit Papillault <benoit.papillault@free.fr>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This fixes IBSS beacon transmissions without VEOL enabled
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The functionality to keep the device awake until it is done with
the rx of any mcast/bcast frames which are pending on AP should
also be added to the hardwares which support auto sleep feature.
This patch fixes frequent failures in ARP resolution when it is
initiated by the other end. Currently auto sleep is enabled only
for ar9003 in ath9k.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is obviously a small picky thing.  The original error handling code
doesn't free the most recent allocations which haven't been added to the
hif_dev->tx.tx_buf list yet.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Acked-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

After c11d8f89: "ath9k_htc: Simplify TX URB management" we no longer
assume that tx_buf is a non-null pointer.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Acked-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This reverts commit 03ceedea.

This patch was reported to cause a regression in which connectivity is
lost and cannot be reestablished after a suspend/resume cycle.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Implicit slab.h inclusion via percpu.h is about to go away.  Make sure
gfp.h or slab.h is included as necessary.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We should use the same buffer size we set up for DMA also in the hardware
descriptor. Previously we used common->rx_bufsize for setting up the DMA
mapping, but used skb_tailroom(skb) for the size we tell to the hardware in the
descriptor itself. The problem is that skb_tailroom(skb) can give us a larger
value than the size we set up for DMA before. This allows the hardware to write
into memory locations not set up for DMA. In practice this should rarely happen
because all packets should be smaller than the maximum 802.11 packet size.

On the tested platform rx_bufsize is 2528, and we allocated an skb of 2559
bytes length (including padding for cache alignment) but sbk_tailroom() was
2592. Just consistently use rx_bufsize for all RX DMA memory sizes.

Also use the return value of the descriptor setup function.

Cc: stable@kernel.org
Signed-off-by: NBruno Randolf <br1@einfach.org>
Reviewed-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We tried to squeeze as much AR9003 support into this kernel
release cycle but there are a few features which are still
being tested and developed. Some of these features are critical
to the stable operation of AR9003 so for now disable AR9003 support
all together. This will get re-enabled once all necessary features
are in place but very likely will not happen for 2.6.35.
Reviewed-by: NDon Breslin <don.breslin@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

For more clearance what the functions actually do,

  usb_buffer_alloc() is renamed to usb_alloc_coherent()
  usb_buffer_free()  is renamed to usb_free_coherent()

They should only be used in code which really needs DMA coherency.

All call sites have been changed accordingly, except for staging
drivers.
Signed-off-by: NDaniel Mack <daniel@caiaq.de>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Pedro Ribeiro <pedrib@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

switch and while statements don't need semicolons at end of statement

[ Fixup minor conflicts with recent wimax merge... -DaveM ]
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch removes from drivers/net/ all the unnecessary
return; statements that precede the last closing brace of
void functions.

It does not remove the returns that are immediately
preceded by a label as gcc doesn't like that.

It also does not remove null void functions with return.

Done via:
$ grep -rP --include=*.[ch] -l "return;\n}" net/ | \
  xargs perl -i -e 'local $/ ; while (<>) { s/\n[ \t\n]+return;\n}/\n}/g; print; }'

with some cleanups by hand.

Compile tested x86 allmodconfig only.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

* add support for the Qwest/Actiontec 802AIN Wireless N USB Network Adapter.

lsusb identifies the device as: "ID 1668:1200 Actiontec Electronics, Inc. [hex]"

usb_modeswitch package and appropriate rules are required to switch
the device from "ID 0ace:20ff ZyDas"

Changes-licensed-under: GPL
Signed-off-by: NSteve Tanner <steve.tanner@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Remove the double swapping of the descriptor data structure, instead
keep it little-endian (native format of the eeprom data), and byteswap
on access.
This allows sparse to verify endian access to the eeprom struct.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use ENDPOINT_MAX instead of HST_ENDPOINT_MAX.
This fixes a stack corruption issue.

This is based on a patch sent by Dan Carpenter <error27@gmail.com>.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The ready message from the target could be processed
before the host HW init has completed. In this case,
htc_process_target_rdy() would assume the target has timed
out, when it hasn't. Fix this by checking if the target
has sent the ready message properly.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The HTC state has to be setup before initializing
the target because the ready message could possibly
come before the control endpoints in HTC have been
identified.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The URBs have to be allocated before uploading
the firmware to the target. This is needed to process
the target ready message properly.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since ->sta_notify() can sleep, protect
the callback with a mutex.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Don't send them for further processing.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

These changes include:

  * For PAPRD, the TXRF3.capdiv5G, TXRF3.rdiv5G and TXRF3.rdiv2G
    are set to 0x0, the TXRF6.capdiv2G is set to 0x2 for all
    three chains.
  * The d2cas5G/d3cas5G/d4cas5G was updated to 4/4/4 in lowest_ob_db
    Tx gain table.
  * To improve DPPM, three parameters were updated (Released from Madhan):
	1. RANGE_OSDAC is set to 0x1 for 2G, 0x0 for 5G
	2. offsetC1 is set to 0xc
	3. inv_clk320_adc is set to 0x1
  * To reduce PHY error(from spur), cycpwr_thr1 and cycpwr_thr1_ext
    are increased to 0x8 at 2G.
  * The 2G Rx gain tables are updated with mixer gain setting 3,1,0.

The new checksums yield:

initvals -f ar9003
0x00000000c2bfa7d5        ar9300_2p0_radio_postamble
0x00000000ada2b114        ar9300Modes_lowest_ob_db_tx_gain_table_2p0
0x00000000e0bc2c84        ar9300Modes_fast_clock_2p0
0x00000000056eaf74        ar9300_2p0_radio_core
0x0000000000000000        ar9300Common_rx_gain_table_merlin_2p0
0x0000000078658fb5        ar9300_2p0_mac_postamble
0x0000000023235333        ar9300_2p0_soc_postamble
0x0000000054d41904        ar9200_merlin_2p0_radio_core
0x00000000748572cf        ar9300_2p0_baseband_postamble
0x000000009aa5a0a4        ar9300_2p0_baseband_core
0x000000003df9a326        ar9300Modes_high_power_tx_gain_table_2p0
0x000000001cfba124        ar9300Modes_high_ob_db_tx_gain_table_2p0
0x0000000011302700        ar9300Common_rx_gain_table_2p0
0x00000000e3eab114        ar9300Modes_low_ob_db_tx_gain_table_2p0
0x00000000c9d66d40        ar9300_2p0_mac_core
0x000000001e1d0800        ar9300Common_wo_xlna_rx_gain_table_2p0
0x00000000a0c54980        ar9300_2p0_soc_preamble
0x00000000292e2544        ar9300PciePhy_pll_on_clkreq_disable_L1_2p0
0x000000002d3e2544        ar9300PciePhy_clkreq_enable_L1_2p0
0x00000000293e2544        ar9300PciePhy_clkreq_disable_L1_2p0

Cc: Don Breslin <don.breslin@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Jumbo frames are not supported, and if they are seen it is likely
a bogus frame so just silently discard them instead of warning on
them all time. Also, instead of dropping them immediately though
move the check *after* we check for all sort of frame errors. This
should enable us to discard these frames if the hardware picks
other bogus items first. Lets see if we still get those jumbo
counters increasing still with this.

Jumbo frames would happen if we tell hardware we can support
a small 802.11 chunks of DMA'd frame, hardware would split RX'd
frames into parts and we'd have to reconstruct them in software.
This is done with USB due to the bulk size but with ath5k we
already provide a good limit to hardware and this should not be
happening.

This is reported quite often and if it fills the logs then this
needs to be addressed and to avoid spurious reports.

Cc: stable@kernel.org
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There are several places that use > ARRAY_SIZE() instead of
>= ARRAY_SIZE().
Signed-off-by: NDan Carpenter <error27@gmail.com>
Acked-by: NBob Copeland <me@bobcopeland.com>
Acked-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

I changed "> ATH9K_HTC_MAX_TID" to ">= ATH9K_HTC_MAX_TID" to avoid a
potential overflow.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Acked-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is a stray null dereference.  We initialize "ista" properly later on.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Acked-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Cc: Paul Shaw <paul.shaw@atheros.com>
Cc: Don Breslin <don.breslin@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Switch LED off/on when handling CONF_CHANGE_IDLE.
Not doing this would leave the radio LED on even
though the chip would be in full sleep mode.
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Generated using the new shiny intivals-tool [1]:

initvals -w -f ar9003 > ar9003_initvals.h

The respective checksums are:

0x000000005a76829d        ar9300_2p0_radio_postamble
0x000000009d90cb74        ar9300Modes_lowest_ob_db_tx_gain_table_2p0
0x00000000e0bc2c84        ar9300Modes_fast_clock_2p0
0x00000000852fca34        ar9300_2p0_radio_core
0x0000000000000000        ar9300Common_rx_gain_table_merlin_2p0
0x0000000078658fb5        ar9300_2p0_mac_postamble
0x0000000023235333        ar9300_2p0_soc_postamble
0x0000000054d41904        ar9200_merlin_2p0_radio_core
0x00000000618455d4        ar9300_2p0_baseband_postamble
0x000000009aa590a4        ar9300_2p0_baseband_core
0x000000004783d946        ar9300Modes_high_power_tx_gain_table_2p0
0x000000006681db44        ar9300Modes_high_ob_db_tx_gain_table_2p0
0x000000001f318700        ar9300Common_rx_gain_table_2p0
0x000000009990cb74        ar9300Modes_low_ob_db_tx_gain_table_2p0
0x00000000c9d66d40        ar9300_2p0_mac_core
0x0000000039139500        ar9300Common_wo_xlna_rx_gain_table_2p0
0x00000000a0c54980        ar9300_2p0_soc_preamble
0x00000000292e2544        ar9300PciePhy_pll_on_clkreq_disable_L1_2p0
0x000000002d3e2544        ar9300PciePhy_clkreq_enable_L1_2p0
0x00000000293e2544        ar9300PciePhy_clkreq_disable_L1_2p0

[1] http://wireless.kernel.org/en/users/Drivers/ath9k_hw/initvals-tool

Cc: Tom Hammel <thammel@atheros.com>
Cc: Enis Akay <Enis.Akay@Atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ath9k_common (used by ath9k and ath9k_htc) trusts the frames
blessed by hardware as OK are infact correct even if the rate
seen by the driver is unrecognized. ath9k_common just treats
these frames in mac80211 as frames as frames under 1 mbps rate.
It seems this might not be the best thing to do as other parts of
the frame might not be valid so just drop these frames for now.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This has no real functional change, this just moves the setting the
the mac80211 rate index into ath9k_process_rate(). This allows us
to eventually make ath9k_process_rate() return a negative value
in case we have detected a specific case rate situation which should
have been ignored.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>