On Thu, 2006-06-22 at 08:12 -0400, Luis R. Rodriguez wrote: > (4) At resume() we could just have our driver read our sysfs > attributes and try to set all of them back exactly how they were > before but to reduce bloat on our drivers and since our state is > already exported we could just have userspace do it for us so... we > use netlink to communicate to userspace to go ahead and ask it to > resume() us. Advantages of this would be userspace would always > consistantly handle the assoc/desassoc and WPA in a consistent manner > and as mentioned above, driver bloatness killing.
I think having the driver try to set all its state back is pretty much useless in a large number of cases. While definitely useful for some cases, consider: a) suspend, drive to work, resume b) WPA-related stuff, which takes much more than simply setting SSID and encryption key back on the card Neither of these instances allows the driver to just stick its fingers in its ears, hum loudly, and pretend nothing happened between suspend and resume. Essentially, drivers would be doing all this work for unencrypted and WEP cases, and then only those cases where the machine hasn't physically moved. Our effort is probably better spent elsewhere, especially since many popular userspace tools already handle resume for us just fine. More useful to have drivers just come back from resume in an initialized state similar to system boot. Dan - 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
