Re: [PATCH] USB: separate autosuspend from external suspend
Alan Stern <[email protected]>
| Newsgroups | gmane.linux.usb.devel |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 14 Mar 2007, Oliver Neukum wrote:
> Am Dienstag, 13. März 2007 21:37 schrieb Alan Stern:
> > +/**
> > + * usb_external_resume_device - external resume of a USB device and its interfaces
> > + * @udev: the usb_device to resume
> > + *
> > + * This routine handles external resume requests: ones not generated
> > + * internally by a USB driver (autoresume) but rather coming from the user
> > + * (via sysfs), the PM core (system resume), or the device itself (remote
> > + * wakeup). @udev's usage counter is unaffected.
> > + *
> > + * The caller must hold @udev's device lock.
> > + */
> > +int usb_external_resume_device(struct usb_device *udev)
> > {
>
> > + usb_pm_lock(udev);
> > + udev->auto_pm = 0;
> > + status = usb_resume_both(udev);
> > + usb_pm_unlock(udev);
> > +
> > + /* Now that the device is awake, we can start trying to autosuspend
> > + * it again. */
> > + if (status == 0)
> > + usb_try_autosuspend_device(udev);
> > return status;
>
> Is itr sensible to resume a device which autosuspend had suspended?
Sure. For example, let's say the user writes "-1" to the
power/autosuspend file. The kernel sets the delay to -1 (thereby
disabling autosuspend in the future) and wakes up the device.
Or maybe the device sends a remote wakeup request, so the kernel has to
resume it.
Alan Stern
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel