- 22 May, 2009 14 commits
-
-
Wey-Yi Guy authored
Add "Greenfield" support for all devices except 4965 and 3945. "Greenfield" is part of 11n features to improve HT performance. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Abhijeet Kolekar authored
'tpt' is a delta throughput (number of packets) and is corelated to brightness of the LED. We already maintain a delta of packets in rxtxpackets. There is no need to calculate this delta again which was affecting the behaviour of LEDS. Also add two new callback functions for ASSOCIATED/DISASSOCIATED states where LED's will be *on* for associated state and *off* for disassociated state. This fixes http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1771. Signed-off-by: Abhijeet Kolekar <abhijeet.kolekar@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bing Zhao authored
The scratch pad register is used to store firmware status after firmware is downloaded and initialized. After firmware status is verified OK, the same register is used to store RX packet length. Hence the firmware status code is no longer valid afterwards. SD8688 firmware introduces a new register for firmware status which will never be overwritten. Also add scratch_reg variable to if_sdio_card structure and initialize it based on the model of the card during probe. Signed-off-by: Bing Zhao <bzhao@marvell.com> Acked-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Zhu Yi authored
This driver supports Intel's full MAC wireless multicomm 802.11 hardware. Although the hardware is a 802.11agn device, we currently only support 802.11ag, in managed and ad-hoc mode (no AP mode for now). 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>
-
Zhu Yi authored
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>
-
Johannes Berg authored
My first patch submission used 200ms, which I then somehow managed to revert back to the earlier 50ms I had used for some tests in the second patch submission -- but that was wrong, I should have used 200ms here. Correct that. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Jouni Malinen authored
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>
-
Jouni Malinen authored
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>
-
Bing Zhao authored
SD8688 is a WLAN/Bluetooth combo chip and both functions are supported in a single firmware image. FUNC_INIT and FUNC_SHUTDOWN commands are implemented to utilize the multiple function feature. When SD8688 card is inserted, the firmware image should be downloaded only once through either WLAN function (Libertas driver) or Bluetooth function (Bluetooth driver). This patch adds function init/shutdown for SD8688 WLAN function only. Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bing Zhao authored
Usually, the 16-bit rx length is read from scratch pad registers with two CMD52 transactions: SD8385: IF_SDIO_SCRATCH_OLD (0x80fe/0x80ff) SD8686/SD8688: IF_SDIO_SCRATCH (0x34/0x35) Alternatively, SD8688 firmware offers an enhanced method for driver to read an 8-bit rx length (in units) with a single CMD52: IF_SDIO_RX_UNIT 0x43 is read one time after firmware is ready. IF_SDIO_RX_LEN 0x42 is read every time when rx interrupt is received. Signed-off-by: Bing Zhao <bzhao@marvell.com> Acked-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bing Zhao authored
replace direct usages of SDIO model numbers with defined macros. Signed-off-by: Bing Zhao <bzhao@marvell.com> Acked-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
andrey@cozybit.com authored
The GPSI interface driver does not re-enable the Card Event Interrupt, which causes problems after a card event (for example: link-loss) comes in. This can lead, for example, to the card failing to re-associate. This patch ensures that we re-enable the Card Event Interrupt when we handle card events. Signed-off-by: Andrey Yurovsky <andrey@cozybit.com> Acked-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
In "mac80211: split out and decrease probe wait time" I tried to reduce the time waiting for a probe response, but failed to take into account the case where we are detecting beacon loss in software -- in that case we still wait the monitoring time rather than the probe wait time. Fix this by refactoring the mod_timer() calls in ieee80211_associated(). Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
The requirement for wireless stats to be atomic is now mostly artificial since we hold the rtnl _and_ the dev_base_lock for iterating the device list. Doing that is not required, just the rtnl is sufficient (and the rtnl is required for other reasons outlined in commit "wext: fix get_wireless_stats locking"). This will fix http://bugzilla.kernel.org/show_bug.cgi?id=13344 and make things easier for drivers. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 20 May, 2009 26 commits
-
-
Johannes Berg authored
Currently, we will ask the driver to configure right away when somebody changes the desired BSSID. That's totally strange because then we will configure the driver without even knowing whether the BSS exists. Change this to only configure the BSSID when associated, and configure a zero BSSID when not associated. As a side effect, this fixes an issue with the iwlwifi driver which doesn't implement sta_notify properly and uses the BSSID instead and gets very confused if the BSSID is cleared before we disassociate, which results in the warning Marcel posted [1] and iwlwifi bug 1995 [2]. [1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/32598 [2] http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1995 Cc: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
Device drivers using wiphy_apply_custom_regulatory() want some regulatory settings applied to their wiphy, if no bands were configured on the wiphy then something went wrong. Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
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>
-
Johannes Berg authored
When I fixed the crypto bit I must have done the negative test only -- it is quite clearly impossible to find _any_ IBSS to join with the parameters put the wrong way around. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
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>
-
Johannes Berg authored
When the genIE hasn't changed there's no reason to kick the state machine since it won't be able to do anything new -- doing this decreases the useless work we do for reassociating because if we do kick the state machine it will try to find a usable BSS but there might not be one because wpa_supplicant will only change the BSSID a little later. In a sense this is a workaround for userspace behaviour, but on the other hand userspace cannot really keep track of what the kernel currently has for genIE since any process could have changed that while wpa_supplicant wasn't looking. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Alexandre Becholey authored
Report status unknown as if there were successfully transmitted. This will avoid hostapd to disassociate because it doesn't understand what a status unknown is. Signed-off-by: Alexandre Becholey <alexandre.becholey@epfl.ch> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Jouni Malinen authored
When updating the duration field for TX frames, skip the update for PS-Poll frames that use this field for other purposes (AID). Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Jouni Malinen authored
If the AP includes our AID in the TIM IE, we need to process the Beacon frame as far as PS is concerned (send PS-Poll or nullfunc data with PM=0). The previous code skipped this in cases where the CRC value did not change and it would not change if the AP continues including our AID in the TIM.. There is no need to count the crc32 value for directed_tim with this change, so we can remove that part. In order not to change the order of operations (i.e., update WMM parameters prior to sending PS-Poll), the CRC match is checked twice as only after the PS processing step, the rest of the function is skipped if nothing changed in the Beacon. Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Jouni Malinen authored
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>
-
Jouni Malinen authored
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>
-
Jouni Malinen authored
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>
-
Jouni Malinen authored
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>
-
Jouni Malinen authored
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>
-
Johannes Berg authored
Moving information from config_interface to bss_info_changed removed struct ieee80211_if_conf which the documentation still refers to, additionally there's one kernel-doc description too much and one other missing, fix all this. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ivo van Doorn authored
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Pavel Roskin authored
If CONFIG_CFG80211_DEBUGFS is enabled and CONFIG_MAC80211_DEBUGFS is not, compilation fails in net/wireless/debugfs.c: net/wireless/debugfs.c: In function 'cfg80211_debugfs_drv_add': net/wireless/debugfs.c:117: error: 'struct cfg80211_registered_device' has no member named 'debugfs' The debugfs filed is needed if and only if CONFIG_CFG80211_DEBUGFS is enabled, so use that instead of CONFIG_MAC80211_DEBUGFS. Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bob Copeland authored
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>
-
Luis R. Rodriguez authored
There is a race on access to last_request and its alpha2 through reg_is_valid_request() and us possibly processing first another regulatory request on another CPU. We avoid this improbably race by locking with the cfg80211_mutex as we should have done in the first place. While at it add the assert on locking on reg_is_valid_request(). Cc: stable@kernel.org Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
This has no functional change, but it will make the race fix easier to spot in my next patch. Cc: stable@kernel.org Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
This has no functional change except we save a kfree(rd) and allows us to clean this code up a bit after this. We do avoid an unnecessary kfree(NULL) but calling that was OK too. Cc: stable@kernel.org Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Wei Yongjun authored
This patch fix to set dev->broadcast correctly, since dev->broadcast is defined as: unsigned char broadcast[MAX_ADDR_LEN]; Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Alexander Beregalov authored
Fix this build error: drivers/staging/agnx/pci.c: In function 'agnx_config_interface': drivers/staging/agnx/pci.c:315: error: dereferencing pointer to incomplete type .. drivers/staging/agnx/pci.c:424: error: unknown field 'config_interface' specified in initializer config_interface was removed in 2d0ddec5 ("mac80211: unify config_interface and bss_info_changed") Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Vasanthakumar Thiagarajan authored
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>
-
Johannes Berg authored
Some applications using wireless extensions expect to be able to remove a key that doesn't exist. One example is wpa_supplicant which doesn't actually change behaviour when running into an error while trying to do that, but it prints an error message which users interpret as wpa_supplicant having problems. The safe thing to do is not change the behaviour of wireless extensions any more, so when the driver reports -ENOENT let the wext bridge code return success to userspace. To guarantee this, also document that drivers should return -ENOENT when the key doesn't exist. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Daniel Wagner authored
Currently all radios receive all traffic on the simulated air if they are tuned to the same channel. This patch introduces the concept of grouping, which allows to assign a radio to certain group. Only radios in the same group can 'see' each other. Each bit in /debug/ieee80211/phy*/hwsim/group represents one group. By default all radios belong to the same group "1", e.g. bit 1 is set. Additionally a radio can belong to several groups. Signed-off-by: Daniel Wagner <wagi@monom.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-