- 29 8月, 2009 1 次提交
-
-
由 Johannes Berg 提交于
Since configure_filter can sleep now, any multicast configuration needed to be postponed to a work struct. This, however, lead to a problem that we could queue the work, stop the device and then afterwards invoke configure_filter which may lead to driver hangs and is a bug. To fix this, we can just cancel the filter work since it's unnecessary to do after stopping the hw. Since there are various places that call drv_stop, and two of them do very similar things, the code for them can be put into a shared function at the same time. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Reported-by: NLennert Buytenhek <buytenh@wantstofly.org> Tested-by: NLennert Buytenhek <buytenh@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 05 8月, 2009 2 次提交
-
-
由 Luis R. Rodriguez 提交于
The mac80211 workqueue exists to enable mac80211 and drivers to queue their own work on a single threaded workqueue. mac80211 takes care to flush the workqueue during suspend but we never really had requirements on drivers for how they should use the workqueue in consideration for suspend. We extend mac80211 to document how the mac80211 workqueue should be used, how it should not be used and finally move raw access to the workqueue to mac80211 only. Drivers and mac80211 use helpers to queue work onto the mac80211 workqueue: * ieee80211_queue_work() * ieee80211_queue_delayed_work() These helpers will now warn if mac80211 already completed its suspend cycle and someone is trying to queue work. mac80211 flushes the mac80211 workqueue prior to suspend a few times, but we haven't taken the care to ensure drivers won't add more work after suspend. To help with this we add a warning when someone tries to add work and mac80211 already completed the suspend cycle. Drivers should ensure they cancel any work or delayed work in the mac80211 stop() callback. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Bob Copeland 提交于
When downing interfaces, it's a good idea to tell the driver to stop sending beacons; that way the driver doesn't need special code in ops->remove_interface() when it should already handle the case in bss_info_changed(). This fixes a potential crash with at least ath5k since the vif pointer will be nullified while beacon interrupts are still active. Signed-off-by: NBob Copeland <me@bobcopeland.com> Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 30 7月, 2009 1 次提交
-
-
由 Johannes Berg 提交于
Jan reported that his b43-based laptop hangs during suspend. The problem turned out to be mac80211 asking the driver to stop the hardware before removing interfaces, and interface removal caused b43 to touch the hardware (while down, which causes the hang). This patch fixes mac80211 to do reorder these operations to have them in the correct order -- first remove interfaces and then stop the hardware. Some more code is necessary to be able to do so in a race-free manner, in particular it is necessary to not process frames received during quiescing. Fixes http://bugzilla.kernel.org/show_bug.cgi?id=13337. Reported-by: NJan Scholz <scholz@fias.uni-frankfurt.de> Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 21 5月, 2009 1 次提交
-
-
由 Johannes Berg 提交于
We forgot to cancel all timers in mac80211 when suspending. In particular we forgot to deal with some things that can cause hardware reconfiguration -- while it is down. While at it we go ahead and add a warning in ieee80211_sta_work() if its run while the suspend->resume cycle is in effect. This should not happen and if it does it would indicate there is a bug lurking in either mac80211 or mac80211 drivers. With this now wpa_supplicant doesn't blink when I go to suspend and resume where as before there where issues with some timers running during the suspend->resume cycle. This caused a lot of incorrect assumptions and would at times bring back the device in an incoherent, but mostly recoverable, state. Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 07 5月, 2009 1 次提交
-
-
由 Johannes Berg 提交于
In order to later add tracing or verifications to the driver calls mac80211 makes, this patch adds static inline wrappers for all operations. All calls are now written as drv_<op>(local, ...); instead of local->ops-><op>(&local->hw, ...); Where necessary, the wrappers also do existence checking and return default values as appropriate. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 23 4月, 2009 2 次提交
-
-
由 Johannes Berg 提交于
Some hardware defects may require the hardware to be re-initialised completely from scratch. Drivers would need much information (for instance the current MAC address, crypto keys, beaconing information, etc.) stored duplicated from mac80211 to be able to do this, so let mac80211 help them. The new ieee80211_restart_hw() function requires the same code as resuming, so move that code into a new ieee80211_reconfig() function in util.c and leave only the suspend code in pm.c. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
In the normal WPA or RSN case keys are only configured after associating, so we should do that in that order when resuming as well. It shouldn't really matter since we do not send any data at either point, but iwlwifi prefers it this way and it does seem more natural. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 22 4月, 2009 1 次提交
-
-
由 Reinette Chatre 提交于
It is expected that config interface will always succeed as mac80211 will only request what driver supports. The exception here is when a device has rfkill enabled. At this time the rfkill state is unknown to mac80211 and config interface can fail. When this happens we deal with this error instead of printing a WARN. Signed-off-by: NReinette Chatre <reinette.chatre@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 28 3月, 2009 4 次提交
-
-
由 Johannes Berg 提交于
When mac80211 resumes, it currently doesn't reconfigure the interfaces entirely and also doesn't reconfigure BSS information -- fix this. Also, to be able to test this, add a debugfs file that just calls the suspend/resume code to see what happens when we go through that, without needing the time-consuming suspend/resume cycle. (Original version broke the build for CONFIG_PM=n. Define alternative functions for that situation. -- JWL) Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Sujith 提交于
When the driver has been notified with a STA_REMOVE, it tears down the internal ADDBA state. On resume, trying to initiate aggregation would fail because mac80211 has not cleared the operational state for that <TID,STA>. This can be fixed by tearing down the existing sessions on a suspend. Also, the driver can initiate a new BA session when suspend is in progress. This is fixed by marking the station as being in suspend state and denying ADDBA requests for such STAs. Signed-off-by: NSujith <Sujith.Manoharan@atheros.com> Acked-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
To avoid concurrent manipulations of the sta list (which shouldn't be possible at this point, but anyway) we need to hold the sta_lock around iterating the list. At the same time, we do not need to iterate the list at all if the driver doesn't want to be notified. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Acked-by: NBob Copeland <me@bobcopeland.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
Even though userland probably cannot submit packets, there might still be some coming, and that's no good when the driver doesn't expect them. Stop the queues across suspend/resume. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 30 1月, 2009 2 次提交
-
-
由 Bob Copeland 提交于
Drivers can theoretically queue more work in one of their callbacks from mac80211 suspend, so let's flush it once more to be on the safe side, just before calling ->stop(). Signed-off-by: NBob Copeland <me@bobcopeland.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Bob Copeland 提交于
This patch introduces suspend and resume callbacks to mac80211, allowing mac80211 to quiesce its state (bringing down interfaces, removing keys, etc) in preparation for suspend. cfg80211 will call the suspend hook before the device suspend, and resume hook after the device resume. Signed-off-by: NBob Copeland <me@bobcopeland.com> Acked-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-