[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.0610051418540.6897-100000@iolanthe.rowland.org>
Date: Thu, 5 Oct 2006 14:24:19 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Oliver Neukum <oliver@...kum.org>
cc: Pavel Machek <pavel@....cz>, <linux-kernel@...r.kernel.org>,
<linux-usb-devel@...ts.sourceforge.net>
Subject: Re: [linux-usb-devel] error to be returned while suspended
On Thu, 5 Oct 2006, Oliver Neukum wrote:
> Am Donnerstag, 5. Oktober 2006 18:21 schrieb Alan Stern:
> > Currently we don't have any userspace APIs for such a daemon to use. The
> > only existing API is deprecated and will go away soon.
>
> I trust it'll be replaced.
Yes. I think Greg wants to wait until the old API is completely gone.
> > Current thinking is that a driver will suspend its device whenever the
> > device isn't in use. With usblp, that would be whenever the device file
> > isn't open. See the example code in usb-skeleton.c.
>
> In the general case the idea seems insufficient. If I close my laptop's lid
> I want all input devices suspended, whether the corresponding files are
> opened or not. In fact, if I have port level power control I might even
> want to cut power to them.
That's a separate issue. You were talking about runtime suspend, but
closing the laptop's lid is a system suspend.
Assuming some sort of mechanism is in place to do a suspend-to-RAM or
suspend-to-disk when the lid is closed, the driver's suspend and resume
methods will be called in the normal way. The driver doesn't need to do
anything special to accomodate it.
The only special thing you need to do is autosuspend when the device isn't
in use, so that even when the laptop's lid is open you can still avoid
using unnecessary power.
Alan Stern
P.S.: Cutting off port power is yet another issue. It isn't a suspend in
the strict sense, because it will break an existing power session.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists