summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/ath
AgeCommit message (Collapse)AuthorFilesLines
2009-06-10ath5k: minor rfkill cleanupBob Copeland6-26/+8
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: Bob Copeland <me@bobcopeland.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-10ath9k: Fix tx stuck when connected to aggr disabled HT APVasanthakumar Thiagarajan1-0/+1
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: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-10ath5k: added cfg80211 based rfkill supportTobias Doerffel7-17/+163
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: John W. Linville <linville@tuxdriver.com>
2009-06-10ar9170: xmit code revampChristian Lamparter5-260/+550
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: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-10ar9170: interpret firmware debug commandsJohannes Berg1-0/+32
This adds new commands that the original firmware will not send but we can use them to debug firmware. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-04ar9170: remove deprecated codeChristian Lamparter2-8/+0
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: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03ath5k: disable beacon interrupt when interface is downBob Copeland1-1/+16
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: Bob Copeland <me@bobcopeland.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03ath: make regulatory parsing more verbose on debugLuis R. Rodriguez1-4/+25
This should help when reviewing issues regarding regulatory domain on ath5k/ath9k/ar9170. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03ath9k: Fix write callback of 'debug' which configures debug maskVasanthakumar Thiagarajan1-8/+14
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: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03rfkill: rewriteJohannes Berg3-107/+30
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: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad] Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03ar9170: cancel led worker properly on exitChristian Lamparter1-3/+7
"[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: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03ar9170usb: more minor fixesChristian Lamparter3-16/+10
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: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03ar9170: fix lockdep warning on hibernateChristian Lamparter1-4/+1
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: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03ar9170: fix LED power state handlingChristian Lamparter2-2/+6
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: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03ar9170: kill duplicated HT feature flagChristian Lamparter1-1/+0
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: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03ar9170: use bitop macros for tx filter flagsChristian Lamparter2-9/+19
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: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03ar9170: introduce functions for MAC programmingChristian Lamparter3-29/+81
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: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03ar9170: 40mhz fixesChristian Lamparter1-3/+3
This patch replace a few constant magics which may affected the device when operating in a 40MHz channel. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03ar9170: update hardware definitionsChristian Lamparter2-3/+4
This patch only contains a few uncritical updates for the hardware definition header. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03ar9170: fix beacon plcp settingsChristian Lamparter1-2/+2
This patch fixes a simple copy & paste error that affected beacon transmission in 802.11a mode. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03ar9170: add AVM FRITZ devicesLuis R. Rodriguez2-0/+27
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: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03ar9170: add support for 1-stage firmwareLuis R. Rodriguez1-5/+17
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: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03ath9k: Add sanity check for beacon_int in adhoc/mesh caseJouni Malinen1-0/+8
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: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03ath5k: remove conf->beacon_int usageBob Copeland1-2/+0
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: Bob Copeland <me@bobcopeland.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03ath9k: Add "debug" file to debugfsJeff Hansen2-0/+39
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: Jeff Hansen <x@jeffhansen.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03ath9k: Combine legacy and 11n rc statisticsJeff Hansen2-85/+35
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: Jeff Hansen <x@jeffhansen.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03ath9k: Reset SC_OP_TSF_RESET flag after stuck beaconJeff Hansen1-0/+1
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: Jeff Hansen <x@jeffhansen.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03ath5k: avoid leaking mutex in ath5k_configJohn W. Linville1-2/+3
Reported-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-25Merge branch 'master' of ↵David S. Miller1-3/+3
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: drivers/net/wireless/ath/ath5k/phy.c drivers/net/wireless/iwlwifi/iwl-agn.c drivers/net/wireless/iwlwifi/iwl3945-base.c
2009-05-22wireless: move some utility functions from mac80211 to cfg80211Zhu Yi3-7/+7
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: Zhu Yi <yi.zhu@intel.com> Signed-off-by: Samuel Ortiz <samuel.ortiz@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-22ath9k: Update Beacon timers based on timestamp from the APJouni Malinen3-1/+16
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: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-22ath9k: Optimize TBTT/DTIM calculation for timersJouni Malinen1-7/+21
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: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-20ath9k: set max default eirp to 20 dBmLuis R. Rodriguez1-2/+2
This is always discarded anyway but lets just set this to our safest lowest. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-20ath9k: fix custom regulatory call positionLuis R. Rodriguez1-4/+7
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: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-20ath9k: Set PM field in frame control when in PS modeJouni Malinen1-0/+15
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: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-20ath9k: Wake up for RX filter changesJouni Malinen1-0/+2
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: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-20ath9k: Use TSFOOR interrupt to trigger TSF sync with next BeaconJouni Malinen1-0/+10
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: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-20ath9k: Do not try to calibrate radio when in sleep modeJouni Malinen1-0/+8
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: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-20ath9k: Wake up for TX in mac80211 timeout=0 sleep modeJouni Malinen4-4/+58
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: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-20ath5k: avoid and warn on potential infinite loopBob Copeland1-0/+3
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: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-20ath9k: Move PS wakeup/restore calls from isr to taskletVasanthakumar Thiagarajan2-15/+9
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: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-20ath5k: update beacons in AP modeBob Copeland1-14/+40
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: Bob Copeland <me@bobcopeland.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-20ath9k: cleanup beacon parameters configurationVasanthakumar Thiagarajan2-28/+36
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: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-20ath9k: Remove unused parameters which are passed to ath_beacon_config_X()Vasanthakumar Thiagarajan1-8/+5
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-20ath9k: Print hw reset failure status as signed intVasanthakumar Thiagarajan2-6/+6
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-20ath9k: Fix PS mode operation to receive buffered broadcast/multicast framesJouni Malinen3-7/+114
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: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-20ath9k: Clean up RX processing a bitJouni Malinen1-26/+34
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: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-20ath9k: Fix a check for multicast address for virtual wiphyJouni Malinen1-1/+1
The broadcast bit is in the first, not the last octet.. Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-20cfg80211: Process regulatory max bandwidth checks for HT40Luis R. Rodriguez1-4/+6
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: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-05-19Merge branch 'master' of ↵David S. Miller2-11/+15
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: drivers/scsi/fcoe/fcoe.c
generated by cgit v1.2.3 (git 2.39.0) at 2024-12-13 12:37:20 +0300