On Tue, 30 Dec 2008, Bob Copeland wrote: > On Tue, Dec 30, 2008 at 10:45 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > >> Is it possible to fix this without suspend support in mac80211? If not, > >> I vote we change rtl8187 (and zd_usb) to prevent suspend. I.e. set USB > >> suspend callbacks which return an error. > > Alan J: > > Are you using 'echo -n mem > /sys/power/state' directly to do suspend, > or hitting the power button? I'm guessing we shouldn't be calling > disconnect() when suspending. > > > It certainly should be possible to fix this. For instance, why > > unregister anything during suspend? If ieee80211_unregister_hw() > > weren't called then this problem would go away, right? > > Yes, we shouldn't need to. > > But it's not the suspend() callback that's getting called (the driver > doesn't have one) but disconnect, which unregisters itself from the > upper layers. I just read the stuff in Documentation/usb but admit I > don't fully get the rules. AIUI, without suspend/resume callbacks, > disconnect will sometimes get called on resume? But the original > email is a hang at suspend time? This explains the problem. Yes, drivers that don't have a suspend or resume method will have their disconnect method called when a system suspend occurs. An easy way to prevent this is to add empty suspend and resume methods (and a resume_reset method too). Alternatively, you can allow the disconnect to occur. If the workqueue weren't freezable then the problem would be solved. Which leads to the question: Why have a freezable workqueue if there's no suspend/resume support in the driver? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
