Am Donnerstag 15 Juni 2006 21:58 schrieb Michael Buesch: > I am currently thinking about the best way to correctly > implement PM suspending for wireless drivers. > Currently, the 802.11 stack is not suspend aware (if I talk > about "stack" here, I mostly mean devicescape). > For example, if we suspend the bcm43xx driver, we don't > notify the stack before doing so. That's a bug.
I think the most important question is how a suspend/resume action should be translated. For the managed case, it is clearly an association loss, normally signalled by netif_carrier_on/off() and a corresponding SIOCGIWAP event. Supplicants can act on this. In AP mode, suspend is equal to disassociating all stations. Ad-hoc... dunno. For a softmac stack like devicescape, it makes sense to have a function that abstracts these scenarios as it is the stack anyway that handles association stuff. However, I'd rather extend the existing function ieee80211_netif_oper(). > The suspend would save all status information, for example > to which AP we are associated and so on. After that it would > cleanly disassociate from the AP and do other cleanups which > are needed. It would *try* to cleanly disassociate. No way waiting for the management packet to reach the air or even for the AP's acknowledgement while half of userspace is already frozen and the user wants the machine to go down ASAP. (But that's an interesting point. Will sniff whether ipw2200 hardware sends a final packet on suspend.) > The resume function would try to re-esablish the connection. Don't keep too much state - just notify userspace of the disassociation, then scan and reassociate using the given iwconfig parameters or the running supplicant as it would happen on a normal association loss. ipw2200 acts like this, and it is definitely fast enough. Stefan - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
