- 23 5月, 2009 10 次提交
-
-
由 Zhu Yi 提交于
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>
-
由 Johannes Berg 提交于
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: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jouni Malinen 提交于
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>
-
由 Jouni Malinen 提交于
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>
-
由 Bing Zhao 提交于
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: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Bing Zhao 提交于
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: NBing Zhao <bzhao@marvell.com> Acked-by: NDan Williams <dcbw@redhat.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Bing Zhao 提交于
replace direct usages of SDIO model numbers with defined macros. Signed-off-by: NBing Zhao <bzhao@marvell.com> Acked-by: NDan Williams <dcbw@redhat.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 andrey@cozybit.com 提交于
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: NAndrey Yurovsky <andrey@cozybit.com> Acked-by: NDan Williams <dcbw@redhat.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
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: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
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: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 21 5月, 2009 30 次提交
-
-
由 Johannes Berg 提交于
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: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
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: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
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>
-
由 Johannes Berg 提交于
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: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
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>
-
由 Johannes Berg 提交于
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: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Alexandre Becholey 提交于
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: NAlexandre Becholey <alexandre.becholey@epfl.ch> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jouni Malinen 提交于
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: NJouni Malinen <jouni.malinen@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jouni Malinen 提交于
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: NJouni Malinen <jouni.malinen@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jouni Malinen 提交于
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>
-
由 Jouni Malinen 提交于
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>
-
由 Jouni Malinen 提交于
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>
-
由 Jouni Malinen 提交于
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>
-
由 Jouni Malinen 提交于
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>
-
由 Johannes Berg 提交于
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: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Ivo van Doorn 提交于
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Pavel Roskin 提交于
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: NPavel Roskin <proski@gnu.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Bob Copeland 提交于
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>
-
由 Luis R. Rodriguez 提交于
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: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
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: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luis R. Rodriguez 提交于
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: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Wei Yongjun 提交于
This patch fix to set dev->broadcast correctly, since dev->broadcast is defined as: unsigned char broadcast[MAX_ADDR_LEN]; Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Alexander Beregalov 提交于
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: NAlexander Beregalov <a.beregalov@gmail.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>
-
由 Johannes Berg 提交于
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: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Daniel Wagner 提交于
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: NDaniel Wagner <wagi@monom.org> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Bob Copeland 提交于
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>
-
由 Max Filippov 提交于
Drop test for FW_STATE_RESET in p54spi_work as fw_state is never assigned this value. Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
Process beacon change even if the BSSID doesn't change at the same time. Also fix what I think is a small locking error in b43legacy, there's a spin_unlock_irqrestore that looks out of place. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Max Filippov 提交于
Under high load first data word, read after available data size is sometimes lost in p54spi_rx. It seems to depend on frequency of interrupts and latency of data read request relatively to 'data available' interrupt. The worst consequence of this bug is loss of packet transmission acknowledgement, which in turn causes overflow of tx queues and permanent link loss. Read data size and first data word in one SPI transaction. No packets from LMAC should have length less than 1 word, so this shouldn't interfere with the next read transaction. Also call p54spi_sleep if p54spi_wake succeeded. Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-