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>

ath_regd_init() needs to be called with the wiphy already
properly set with the bands. Without this the custom regulatory
settings were not taking effect, and the device would get
the default channel settings from ath9k_[25]ghz_chantable.
Reported-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

mac80211 does not set PM field for normal data frames, so we need to
update that based on the current PS mode when using PS-Poll
(timeout=0) power save mode.

This allows the AP to remain in sync with our PS state. However, there
is still a potential race condition between PS state changes when
multiple TX queues are used and nullfunc and PS-Poll frames use
different queue. That corner case may need to be handled separately by
changing which queue is used either in ath9k or mac80211.
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We must make sure the chip is awake when changing the RX filter
parameters. This could have caused problems, e.g., when changing the
interface to promiscuous mode while in sleep mode.
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If the chip complains about TSF sync, make sure we remain awake to
sync with the next Beacon frame. In theory, this should not be needed
since we are currently trying to receive all Beacon frames, anyway,
better have this code ready should we ever change that.
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When the chip is in sleep mode, there is no point trying to calibrate
the radio since it will just results in incorrect values being read
from registers and other potential issues. In addition, if we actually
start processing calibrate, do not allow the chip to be put into sleep
until we have completed the calibration step.
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When using timeout=0 (PS-Poll) with mac80211, the driver will need to
wake up for TX requests and remain awake until the TX has been
completed (ACK received or timeout) or until the buffer frame(s) have
been received (in case the TX is for a PS-Poll frame).
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If we are trying to interpolate a curve with slope == 0, the return
value will always be the y-coordinate.  In this code we are looping
until we reach a minimum y-coordinate on a line, which in the 0-slope
case can never happen, thus the loop never terminates.

The PCDAC steps come from the EEPROM and should never be equal, but
we should gracefully handle that case, so warn and bail out.
Reported-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We do not need to do this in ath_isr() and it looks like the modified
version ends up being more stable as far as being able receive beacon
frames is concerned. Furthermore, this reduces need to move between
AWAKE and NETWORK SLEEP states when processing some unrelated
interrupts.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ath5k only generated the beacon when bss_info_changed() was called,
but for AP mode this is not enough, because the TIM IE would never
get updated and consequently PS mode clients wouldn't know about
buffered frames.  Instead, get a new beacon on every SWBA interrupt.
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch configures the beacon timers with beacon interval
and beacon period passed through vif.bss_conf. Also cache the
currecnt beacon configuration which will be used to configure
the beacon timers when the driver triggers it after reset.
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>

The previous implementation was moving back to NETWORK SLEEP state
immediately after receiving a Beacon frame. This means that we are
unlikely to receive all the buffered broadcast/multicast frames that
would be sent after DTIM Beacon frames. Fix this by parsing the Beacon
frame and remaining awake, if needed, to receive the buffered
broadcast/multicast frames. The last buffered frame will trigger the
move back into NETWORK SLEEP state.

If the last broadcast/multicast frame is not received properly (or if
the AP fails to send it), the next Beacon frame will work as a backup
trigger for returning into NETWORK SLEEP.

A new debug type, PS (debug=0x800 module parameter), is added to make
it easier to debug potential power save issues in the
future. Currently, this is only used for the Beacon frame and buffered
broadcast/multicast receiving.
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This makes use of the local fc variable in bit more places and uses a
common helper macro. The part of RX process that delivers skb's to
mac80211 is moved to a separate function in preparation for future
changes that will need to do this from two places. The modifications
here should not result in any functional changes.
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The broadcast bit is in the first, not the last octet..
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We are not correctly listening to the regulatory max bandwidth
settings. To actually make use of it we need to redesign things
a bit. This patch does the work for that. We do this to so we
can obey to regulatory rules accordingly for use of HT40.

We end up dealing with HT40 by having two passes for each channel.

The first check will see if a 20 MHz channel fits into the channel's
center freq on a given frequency range. We check for a 20 MHz
banwidth channel as that is the maximum an individual channel
will use, at least for now. The first pass will go ahead and
check if the regulatory rule for that given center of frequency
allows 40 MHz bandwidths and we use this to determine whether
or not the channel supports HT40 or not. So to support HT40 you'll
need at a regulatory rule that allows you to use 40 MHz channels
but you're channel must also be enabled and support 20 MHz by itself.

The second pass is done after we do the regulatory checks over
an device's supported channel list. On each channel we'll check
if the control channel and the extension both:

 o exist
 o are enabled
 o regulatory allows 40 MHz bandwidth on its frequency range

This work allows allows us to idependently check for HT40- and
HT40+.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch makes the return type of some of the functions
void as those functions always return true
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>