An earlier commit, 'ath9k: remove dummy PCI "retry timeout" fix', removed
code that was documented to disable RETRY_TIMEOUT register (PCI reg
0x41) since it was claimed to be a no-op. However, it turns out that
there are some combinations of hosts and ath9k-supported cards for
which this is not a no-op (reg 0x41 has value 0x80, not 0) and this
code (or something similar) is needed. In such cases, the driver may
be next to unusable due to very frequent PCI FATAL interrupts from the
card.

Reverting the earlier commit, i.e., restoring the RETRY_TIMEOUT
disabling, seems to resolve the issue. Since the removal of this code
was not based on any known issue and was purely a cleanup change, the
safest option here is to just revert that commit. Should there be
desire to clean this up in the future, the change will need to be
tested with a more complete coverage of cards and host systems.

http://bugzilla.kernel.org/show_bug.cgi?id=13483

Cc: stable@kernel.org
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If we are in PS mode, we have to process the received frame if
the SC_OP_WAIT_FOR_CAB bit is set.

Changes-licensed-under: ISC
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We have to remain awake if the SC_OP_WAIT_FOR_CAB flag is set.

Changes-licensed-under: ISC
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The ath9k_ps_{wakeup,restore} calls must be in balance.

Changes-licensed-under: ISC
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This ports the ath9k rfkill code to the new API offered by
cfg80211 and thus removes a lot of useless stuff.

("With this series a kernel panic, which is a regression, during module
unload disappears." -- Vasanthakumar Thiagarajan <vasanth@atheros.com>

Other patches in the series:

  ath9k: Add helper to get ath9k specific current channel
  ath9k: Make sure we have current channel in ah_curchan before rf
    disable/enable

-- JWL)
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Cc: Luis Rodriguez <mcgrof@gmail.com>
Tested-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@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>

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

This patch is from Nick Kossifidis but he forgot to send it.  It ensures
that the beacon queue gets started in mesh mode as well, otherwise ath5k
will not beacon in mesh point mode.

At this time, we still need to issue a scan before mesh beaconing will
work but that appears to be a separate problem.
Signed-off-by: NAndrey Yurovsky <andrey@cozybit.com>
Signed-off-by: NNick Kossifidis <mickflemm@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Always enable rfkill since the ifdefs in the code is not really worth
the Kconfig option.  Also fix a few code style things, and remove the
usage of the ah_gpio[] array so we can remove it later.
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch along with my previous patch in mac80211 "Fix the
way ADDBA count..", fixes hang in tx when connected to an HT
AP which rejects/times out on addba req.

AGGR_ADDBA_PROGRESS should be cleared in aggr state when addba
negotiation is terminated due to either addba response is timed out
or addba is denied by the AP. With out clearing this bit,
all frames are queued onto s/w queue for getting tx'd as aggr and
will never be scheduled onto hw queue.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch introduces initial rfkill support for the ath5k driver
based on rfkill support in the cfg80211 framework.
All rfkill related code is separated into newly created rfkill.c.

Changes to existing code are minimal:

* added a new data structure ath5k_rfkill to the ath5k_softc structure
* inserted calls to HW rfkill init/deinit routines
* ath5k_intr() has been extended to handle AR5K_INT_GPIO interrupts
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch is a back-port from aggregation testing code.

In the past, we didn't limit the amount of active tx urbs.
However, ar9170 only has a limited buffer reserved for
pending data frames.

This wasn't much of a problem with the slower 802.11b/g.
We simply stopped the full queue and moved on to something different
in the mean time. But - as you guessed it -  this simple approach
stands in way for a decent aggregation implementation.
Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This adds new commands that the original firmware will not send
but we can use them to debug firmware.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch removes code (deprecated by "cfg80211: add rfkill support" )

main.c: In function 'ar9170_op_config':
main.c:1306: warning: '__IEEE80211_CONF_CHANGE_RADIO_ENABLED'
is deprecated (declared at include/net/mac80211.h:551)

and a useless device state.
Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When we remove the active interface, there's no need to continue
sending beacons; doing so would cause a null pointer deref in
ieee80211_beacon_get().  Disable the interrupt in remove_interface
and add a WARN_ON(!vif) in case there are other instances lurking.
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This should help when reviewing issues regarding regulatory
domain on ath5k/ath9k/ar9170.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Handle error condition on copy_from_user() properly and
make sure a NUL terminated char[] is sent to strict_strtoul()
for proper conversion.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch completely rewrites the rfkill core to address
the following deficiencies:

 * all rfkill drivers need to implement polling where necessary
   rather than having one central implementation

 * updating the rfkill state cannot be done from arbitrary
   contexts, forcing drivers to use schedule_work and requiring
   lots of code

 * rfkill drivers need to keep track of soft/hard blocked
   internally -- the core should do this

 * the rfkill API has many unexpected quirks, for example being
   asymmetric wrt. alloc/free and register/unregister

 * rfkill can call back into a driver from within a function the
   driver called -- this is prone to deadlocks and generally
   should be avoided

 * rfkill-input pointlessly is a separate module

 * drivers need to #ifdef rfkill functions (unless they want to
   depend on or select RFKILL) -- rfkill should provide inlines
   that do nothing if it isn't compiled in

 * the rfkill structure is not opaque -- drivers need to initialise
   it correctly (lots of sanity checking code required) -- instead
   force drivers to pass the right variables to rfkill_alloc()

 * the documentation is hard to read because it always assumes the
   reader is completely clueless and contains way TOO MANY CAPS

 * the rfkill code needlessly uses a lot of locks and atomic
   operations in locked sections

 * fix LED trigger to actually change the LED when the radio state
   changes -- this wasn't done before
Tested-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad]
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

"[PATCH 3/4 v2] ar9170: fix LED power state handling" revealed
a bug which can cause a ugly crash.

The delayed worker is canceled before the LED class functions are
unregistered... So, if something manages to update the LEDs
while unregister routine is running the timer could fire _after_ the
module has been unloaded.
Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch contains a few more mostly random fixes for the USB front-end.

1. handle irq command response, instead of printing it to the console.

2. remove fixed FIXME.
    (real fix: "ar9170usb: reset device on resume". )

3. some more one-liner.
	- get rid of a useless "return;"
	- add a few branch prediction hints in hot-paths
	etc.
Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch takes care of Johannes' deadlock report by moving the
mutex_lock right after cancel_work_sync in ar9170_op_stop.

Besides, the janitor does not need to hold the mutex anymore,
so this extra lines can be removed as well.
Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes a minor visual bug in the led code, which
left the LED in the wrong power state when it was toggled
in a _unexpected_ way (e.g: enabling the LED twice).
Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch removes a redundant flag.

.cap	=	IEEE80211_HT_CAP_MAX_AMSDU |	\
>		IEEE80211_HT_CAP_SM_PS |			\ <
		[...]									\
>		IEEE80211_HT_CAP_SM_PS,			\ <
		.ampdu_factor   = 3,					\
Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes a bug in configure_filter's (sub-)routines.
We never really cleared the flags once we updated the hardware state,
so we wasted our resources by applying already active settings.
Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch introduces 3 new function which are used to update
the MAC state, whenever needed... e.g: after a band switch.
Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch replace a few constant magics which may affected
the device when operating in a 40MHz channel.
Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch only contains a few uncritical updates for the
hardware definition header.
Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes a simple copy & paste error that affected beacon
transmission in 802.11a mode.
Signed-off-by: NChristian Lamparter <chunkeey@web.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This adds:

USB 0x057C:0x8401       AVM FRITZ!WLAN USB Stick N
USB 0x057C:0x8402       AVM FRITZ!WLAN USB Stick N 2.4

These devices require the 1-stage firmware, if not present we
don't continue.

Cc: Peter Grabienski <Peter.Grabienski@Atheros.com>
Cc: Stephen Chen <Stephen.Chen@Atheros.com>
Cc: Michael Fortin <Michael.Fortin@Atheros.com>
Cc: Johnny Cheng <Johnny.Cheng@Atheros.com>
Cc: Yuan-Gu Wei <Yuan-Gu.Wei@atheros.com>
Cc: Joerg Albert <jal2@gmx.de>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

You can get the stage 1 firmware from here:

http://www.kernel.org/pub/linux/kernel/people/mcgrof/firmware/ar9170/ar9170.fw

md5sum: 34feec4ec0eae3bb92c7c1ea2dfb4530
sha1sum: 6e5250498b815c2940d97242de31e054ae44e079

Its license:

http://www.kernel.org/pub/linux/kernel/people/mcgrof/firmware/ar9170/LICENSE

This is a new firmware, tested with WNDA3100.

Cc: Peter Grabienski <Peter.Grabienski@Atheros.com>
Cc: Stephen Chen <Stephen.Chen@Atheros.com>
Cc: Michael Fortin <Michael.Fortin@Atheros.com>
Cc: Johnny Cheng <Johnny.Cheng@Atheros.com>
Cc: Yuan-Gu Wei <Yuan-Gu.Wei@atheros.com>
Cc: Joerg Albert <jal2@gmx.de>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It looks like mac80211 can request the driver to start beaconing with
a beacon interval of zero in some cases (at least for mesh point). This
does not sound correct and something may need to be fixed in
mac80211. However, taken into account the unpleasantness of getting
stuck in an infinite busy loop with rtnl_lock held, let's add a quick
workaround in the driver to avoid the worst symptom while someone more
familiar with the mesh implementation can figure out what should be done
with mac80211 as far as beacon interval configuration is concerned.
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ieee80211_conf->beacon_int was deprecated and removed in a cleanup
patch, however it was accidentally added back to ath5k in the change
"ath5k: Allow user/driver to set txpower."  Remove it once more,
fixing the following warning:

[13091.968902] WARNING: at drivers/net/wireless/ath/ath5k/base.c:2167 warn_slowpath_null+0x15/0x1a()
[13091.968906] Hardware name: MacBook1,1
[13091.968909] Modules linked in: usb_storage fuse i915 drm af_packet acpi_cpufreq binfmt_misc dm_mirror dm_region_hash dm_log dm_multipath dm_mod snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_seq_dummy hid_apple arc4 ecb snd_seq_oss snd_seq_midi_event usbhid snd_seq ath5k mac80211 appletouch snd_seq_device snd_pcm_oss snd_mixer_oss sky2 snd_pcm ath processor cfg80211 snd_timer sg ohci1394 snd uhci_hcd bitrev ieee1394 joydev ehci_hcd crc32 snd_page_alloc button ac thermal battery sr_mod applesmc cdrom evdev input_polldev unix [last unloaded: microcode]
[13091.968985] Pid: 2132, comm: phy0 Tainted: G        W  2.6.30-rc5-wl #118
[13091.968988] Call Trace:
[13091.968994]  [<c0125884>] warn_slowpath_fmt+0x77/0xa6
[13091.969003]  [<c03557d8>] ? _spin_unlock+0x2c/0x41
[13091.969008]  [<c0355a56>] ? _spin_lock_irqsave+0x15/0x69
[13091.969012]  [<c0355783>] ? _spin_unlock_irqrestore+0x34/0x5d
[13091.969019]  [<c01445bb>] ? trace_hardirqs_off+0xb/0xd
[13091.969024]  [<c0355783>] ? _spin_unlock_irqrestore+0x34/0x5d
[13091.969029]  [<c01445bb>] ? trace_hardirqs_off+0xb/0xd
[13091.969034]  [<c0355783>] ? _spin_unlock_irqrestore+0x34/0x5d
[13091.969039]  [<c01258c8>] warn_slowpath_null+0x15/0x1a
[13091.969054]  [<f965846d>] ath5k_beacon_update_timers+0x44/0x27f [ath5k]
[13091.969059]  [<c0126370>] ? vprintk+0x2dd/0x312
[13091.969063]  [<c0125e50>] ? release_console_sem+0x1a6/0x1d3
[13091.969076]  [<f96586c5>] ath5k_reset_tsf+0x1d/0x2c [ath5k]
[13091.969095]  [<f93f4426>] __ieee80211_sta_join_ibss+0x35/0x3aa [mac80211]
[13091.969102]  [<c0252793>] ? extract_entropy+0x47/0x8a
[13091.969121]  [<f93f4b21>] ieee80211_sta_find_ibss+0x2de/0x32f [mac80211]
[13091.969126]  [<c035422c>] ? mutex_lock_nested+0x28b/0x2a5
[13091.969145]  [<f93f4b8e>] ? ieee80211_ibss_notify_scan_completed+0x1c/0x6f [mac80211]
[13091.969164]  [<f93f4bc9>] ieee80211_ibss_notify_scan_completed+0x57/0x6f [mac80211]
[13091.969182]  [<f93f26da>] ieee80211_scan_completed+0x31a/0x33f [mac80211]
[13091.969201]  [<f93f27ca>] ieee80211_scan_work+0xcb/0x18b [mac80211]
[13091.969207]  [<c0133a6a>] worker_thread+0x1b1/0x28e
[13091.969212]  [<c0133a25>] ? worker_thread+0x16c/0x28e
[13091.969230]  [<f93f26ff>] ? ieee80211_scan_work+0x0/0x18b [mac80211]
[13091.969237]  [<c013736e>] ? autoremove_wake_function+0x0/0x38
[13091.969242]  [<c01338b9>] ? worker_thread+0x0/0x28e
[13091.969246]  [<c0137031>] kthread+0x4a/0x70
[13091.971460]  [<c0136fe7>] ? kthread+0x0/0x70
[13091.971467]  [<c0103527>] kernel_thread_helper+0x7/0x10
[13091.971470] ---[ end trace 8defaa5d15c50cef ]---
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch adds the debug file to the ath9k debugfs, which lets you modify
the debug_mask at runtime, without having to reload the ath9k module.
Signed-off-by: NJeff Hansen <x@jeffhansen.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch combines the legacy and 11n rcstats into one, using the normal
rate table indices instead of two separate indices for each mode.  Legacy
rates also get all of the PER and retry information, now, too.
Signed-off-by: NJeff Hansen <x@jeffhansen.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

I have a TrendNet 652-BRP running OpenWRT + ath9k very well.  The only
problem is that the beacon gets stuck maybe once a day.  After
Vasanthakumar Thiagarajan's "ath9k: cleanup beacon parameters
configuration" patch, ath9k would nearly re-configure the beacons after it
detected the stuck beacon, and did a reset.  But it would fail the
SC_OP_TSF_RESET check in ath_beacon_config_ap.  This patch gets the beacon
fully reconfigured after the reset.
Signed-off-by: NJeff Hansen <x@jeffhansen.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Reported-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The patch moves some utility functions from mac80211 to cfg80211.
Because these functions are doing generic 802.11 operations so they
are not mac80211 specific. The moving allows some fullmac drivers
to be also benefit from these utility functions.
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NSamuel Ortiz <samuel.ortiz@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some APs seem to drift away from the expected TBTT (timestamp %
beacon_int_in_usec differs quite a bit from zero) which can result in
us waking up way too early to receive a Beacon frame. In order to work
around this, re-configure the Beacon timers after having received a
Beacon frame from the AP (i.e., when we know the offset between the
expected TBTT and the actual time the AP is sending out the Beacon
frame).
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The previous version used a simple loop to go through all Beacon
frames when determining the next TBTT and DTIM count. This is not too
bad for the case where the setup happens before timesync (i.e., very
small TSF), but this can become very heavy operation if a short Beacon
interval is used and the current TSF is large.

In preparation for a patch to update timer setup based on Beacon
timestamp, optimize this routine to take fixed time regardless of the
actual TSF value.
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is always discarded anyway but lets just set this to our
safest lowest.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>