Return-path: Received: from ey-out-2122.google.com ([74.125.78.25]:24249 "EHLO ey-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751446AbYL3RbX (ORCPT ); Tue, 30 Dec 2008 12:31:23 -0500 Message-ID: <495A5AE5.1040902@tuffmail.co.uk> (sfid-20081230_183129_382349_D9668B4F) Date: Tue, 30 Dec 2008 17:31:17 +0000 From: Alan Jenkins MIME-Version: 1.0 To: Alan Stern CC: Bob Copeland , linux-wireless@vger.kernel.org, linux-pm@lists.linux-foundation.org, USB list Subject: Re: [linux-pm] rtl8187 usb wifi adaptor causes suspend hang References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: Alan Stern wrote: > On Tue, 30 Dec 2008, Bob Copeland wrote: > > >> On Tue, Dec 30, 2008 at 10:45 AM, Alan Stern 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? >