Alan Stern wrote: > 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). > That won't fix hibernation though. The disconnect method can still get called in resume from hibernation, before the workqueue gets unfrozen. To be honest, I'm far more interested in suspend-to-disk than suspend-to-ram. > 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? > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
