- 11 Sep, 2008 40 commits
-
-
Ivo van Doorn authored
There isn't really a good reason to have the LED configuration options selectable per driver, lets make it default 'y' and make it depend on the NEW_LEDS and LEDS_CLASS interface. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
RFKILL should be enabled for _all_ hardware whether or not they feature a rfkill button or not. Remove driver specific RFKILL configuration options and make the rt2x00lib version depend on CONFIG_RFKILL and defaulting to 'y' to make sure it will always be enabled when RFKILL was enabled. This also fixes some bugs where RFKILL wasn't initialized and didn't respond to RFKILL key presses. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Cleans up the code a bit and prepares for the next patch that will use the function elsewhere. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
deauth and disassoc frames are completely identical so there's little point in having two functions to send them rather than one that gets a parameter. This same a bit of code size. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This reorders all frame sending functions to be at the top of the file. When reading the file, I tend to be looking at either the frame code or the state machine, and having them mixed in the file is confusing. When all frame sending is at the top the remainder of the file is more readable, in my opinion. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Ever since we refactored beaconing to not be controlled by a fake queue this parameter to ieee80211_sta_def_wmm_params has been unused. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
ieee80211_sta_start_scan() can very well take a non-NULL ssid pointer with a zero ssid_len. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
When a scan is requested for non-STA interfaces, we simply fire off a scan, but for STA interfaces we shouldn't because they could be in the middle of an association. This clarifies the corresponding code. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Now that I've created ht.c, I can move the aggregation code from main.c into it. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Some of the HT code in mlme.c is misplaced: * constants/definitions belong to the ieee80211.h header * code being used in other modes as well shouldn't be there Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This moves all the BSS list handling out of mlme.c to scan.c, no further changes except fixing kzalloc/atomic_inc/atomic_inc to kzalloc/atomic_set(2). Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This patch refactors some code and moves the scan RX function to scan.c. More importantly, however, it changes it so that the MLME's beacon/probe_resp functions aren't invoked when scanning so that we can remove a "if (scanning)" conditions from two places. There's a very slight behavioural change in this patch: now, when scanning, IBSS and mesh aren't updated even on the same channel. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Here's a first patch to move some code from mlme.c to a new file called scan.c. The end result will hopefully be a more manageable mlme.c. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
I'm surprised nobody complained about these before. What a waste. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Since we now use sdata pointers most of the time, using a netdev pointer here is somewhat artificial, use an sdata pointer instead. Replace a netdev-prefix in a few messages by a wiphy-prefix. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This reorders the mlme code a bit so we don't need all the forward function declarations. It also removes the ERP_INFO_USE_PROTECTION define that is unused, but otherwise contains no real changes. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Tomas Winkler authored
During testing of the disassociation fixes, Tomas noticed that it was possible to run into a situation where you'd suddenly get a few "wlan0: dropped frame to <AP> (unauthorized port)" messages and I found this to be due to the AP's sta_info having been removed but netif_carrier_off not having removed/stopped traffic yet. To avoid that, stop the queue for the interface (and avoid bringing them up when another vif scans when they weren't up.) Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Tomas Winkler authored
This patch moves disassociation code from ieee80211_set_associated to ieee80211_set_disassoc. To reduce code duplication, it introduces the ieee80211_sta_send_apinfo function. Additionally, it fixes a lapse where BSS_CHANGED_HT wasn't set when notifying the driver of changes due to disassociation. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Tomas Winkler authored
This patch makes the MLME cleanly disassociate from the current BSS when leaving it for a new one. This is not just nicer to the old AP (we're leaving it, might as well tell it!) but also required for some drivers that keep track of the station we're associated with, they'd get confused because they'd think we are associated with two APs. Signed-off-by: Ron Rindjunsky <ron.rindjunsky@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Tomas Winkler authored
This patch restructure the flow of disassociation and deauthentication flows to be consistent under all circumstances. It ensures that BA session is treated down before deauthentication or disassociation, adds the removal of the obsolete sta form station table and fixes a related bug (sta_info_destroy without sta_info_unlink) in ieee80211_associated() and reduce some code duplication Signed-off-by: Ron Rindjunsky <ron.rindjunsky@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
This reverts: b93ce437 rt2x00: Fix the beacon length bug The workaround is no longer required since it has been correctly fixed in rt2x00usb now. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Since IE parsing is required for the mlme and mesh code, it's not a static function anyway, and it's much better to have it in util rather than the overly large mlme.c Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This says chan_switch.action_code but really means measurement.action_code, of course the actual offset in the frame is the same, it's just harder to understand this way. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
The action frame length checks are one too small, there's not just an action code as the comment makes you believe, there's a category code too, and the category code is required in each action frame (hence part of IEEE80211_MIN_ACTION_SIZE). Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
When we receive information about a BSS we check at some point whether or not we think we're allowed to use the channel it is on, but we do that fairly late. I don't think we should do it that late, so do it earlier to avoid doing IBSS/mesh stuff on that channel and then getting confused because it's disabled. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
The conf_tx callback currently needs to be atomic, this requirement is just because it can be called from scanning. This rearranges it slightly to only update while not scanning (which is fine, we'll be getting beacons when associated) and thus removes the atomic requirement. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
The if itself doesn't need to be protected, so move in the RCU locking to avoid doing anything at all when the condition isn't true. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ehud Gavron authored
Recent changes in the specifications have improved the performance of the BCM4306/2 devices that use b43legacy as the driver. These "errors" in the specs have been present from the very first implementation of bcm43xx. Signed-off-by: Ehud Gavron <gavron@wetwork.net> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Larry Finger authored
A coding error present since b43legacy was incorporated into the kernel has prevented the driver from using the rate-setting mechanism of mac80211. The driver has been forced to remain at a 1 Mb/s rate. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@kernel.org> [2.6.26], [2.6.25] Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Michael Buesch authored
We don't need the workqueue anymore, as we can now sleep in the callback. Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Michael Buesch authored
It causes compile errors on m68k and it is not needed. Remove it. Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Michael Buesch authored
This fixes the initialization of the default QoS parameters. This got broken by "wireless: fix warnings from QoS patch". Reported-by: Lorenzo Nava Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
This patch brings the 5GHz Phy in any prism54 devices (of course, only those who have one) to life. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
I hope this patch is enough to cover at least the basic requirements of IEEE 802.11h's TPC. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
The firmware can provide lots of useful statistics about noise floor, mac time and lots of numbers about successful transfers and dropped frames. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
This patch adds new filters settings to make the card more useful in monitor mode. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Christian Lamparter authored
tcpdump: 02:15:42.874518 61112184us tsft 48.0 Mb/s 2437 MHz (0x0480) antenna 1 [0x0000000e] CF +QoS Data IV 02:15:42.874557 >>>4356079526us<<< tsft 24.0 Mb/s 2437 MHz (0x0480) antenna 1 [0x0000000e] Acknowledgment 02:15:42.976844 61214513us tsft 1.0 Mb/s 2437 MHz (0x0480) antenna 0 [0x0000000e] Beacon as one can see on the huge jump, it's very plausible that firmware does not report the full 64-bit mac time, just the lower 32bit and some kinds of flags... Therefore if we want a useful timestamp we have to emulate the high bits. Signed-off-by: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Zhu Yi authored
The patch fixes compile warning for ‘iwl4965_hw_channel_switch’ defined but not used. Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Emmanuel Grumbach authored
This patch cleans up iwlwifi by removing uneeded declarations and removing uneeded symbol export reducing the namespace pollution. It also fixes some typos in comments. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Grumbach, Emmanuel authored
This patch makes usage of the results from disconnected antenna alg to know how many antennas are connected. It also synchronizes between the chain noise alg and the W/A that disables power management during association. All the antennas must be enables during the chain noise algorithm. Hence, power management is restored only after the completion of the algorithm. In the future, we will need to update the AP that we don't support MIMO if there is only one antenna connected. We also need to update the rate scaling algorithm. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-