Hi driver authors :)
I suggest you guys get together and write some proper suspend support
for mac80211. We can discuss in Ottawa, but I just wanted to let you
know that I just ran into this:
[...]
[55292.062873] adb: starting probe task...
[55292.063012] adb: finished probe task...
[55292.502871] wlan0: No ProbeResp from current AP 00:1a:2a:2c:a2:c5 - assume out of range
[55292.502883] phy2: Removed STA 00:1a:2a:2c:a2:c5
[55292.562874] mac80211-phy2: failed to remove key (0, 00:1a:2a:2c:a2:c5) from hardware (-19)
[55292.563229] phy2: Destroyed STA 00:1a:2a:2c:a2:c5
[55292.768591] hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
[55292.776295] hda: UDMA/100 mode selected
[55292.777058] ide-cdrom 1.0: resuming
[55292.779026] hdc: host max PIO4 wanted PIO255(auto-tune) selected PIO4
[55292.779210] hdc: MWDMA2 mode selected
[55292.779533] therm_adt746x 8-002e: resuming
[55292.779548] b43 ssb0:0: resuming
[55292.779552] b43-phy2 debug: Resuming...
[...]
As you can see, mac80211 "noticed" that the AP was "out of range",
probably because it sent a probe request just before or during
suspending and the time till now was about an hour.
We _really_ need to tie mac80211's workqueues and everything to the
hardware so we don't try to do these things before the driver resumes.
As you can see, mac80211 also complained that the key couldn't be
removed; that is because b43 didn't like being called when the hardware
was still shut down.
I don't even know if b43 keeps hardware keys across suspend (if not that
might explain some of the wpa problems I had with suspend) but it
shouldn't have to. In fact, I think it shouldn't even have to keep the
MAC address setting (it does that now.)
This is not a hard problem to solve.
What needs to be done is:
- extend the ieee80211_notify_mac callback with two new paramters:
suspend and resume
- suspend is called by drivers when suspending _before_ taking any
driver-specific locks, allowing mac80211 to call all callbacks as a
response to that
- resume is called by drivers when resuming _after_ having resumed the
hardware
- suspend does, in this order (callback used):
* stop aggregation (ampdu_action)
* remove all keys (set_key)
* remove all STAs (sta_notify)
* remove all interfaces (remove_interface)
* stop the hardware (stop)
- resume does the opposite in opposite order, and additionally
* updates TKIP phase 1 keys (?)
* re-sets RTS/frag threshold, retry limits
* re-configures hardware (config)
* re-configures TX parameters (conf_tx)
* re-configures filters (configure_filter)
* [probably more that I missed on first sight]
All the values should be there in software state inside mac80211 anyway,
so doing it shouldn't need a significant amount of new state, though one
may have to add something depending on the up/down state of interfaces
to the sdata struct.
It's not _extremely_ complicated, but testing it all and getting it
right is a significant effort. TBH, I'm not bored enough right now to
spend a significant amount of time on it; I know how to recover should
anything go wrong (b43 is a very good driver in that respect, it handles
all those stupid cases that shouldn't happen.)
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
