lk/linux-kernel-test
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

mac80211: cancel/restart all timers across suspend/resume

Browse Source 
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: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This commit is contained in:
Johannes Berg
2009-05-17 11:40:42 +02:00
committed by John W. Linville
parent cc32abd494
commit 5bb644a0fd
12 changed files with 321 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
net/mac80211/scan.c
View File

@@ -631,3 +631,21 @@ int ieee80211_request_internal_scan(struct ieee80211_sub_if_data *sdata,
mutex_unlock(&local->scan_mtx);
return ret;
}
void ieee80211_scan_cancel(struct ieee80211_local *local)
{
bool swscan;
cancel_delayed_work_sync(&local->scan_work);
/*
* Only call this function when a scan can't be
* queued -- mostly at suspend under RTNL.
*/
mutex_lock(&local->scan_mtx);
swscan = local->sw_scanning;
mutex_unlock(&local->scan_mtx);
if (swscan)
ieee80211_scan_completed(&local->hw, true);
}