From: Greg KH <greg@kroah.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Mayuresh Kulkarni <mkulkarni@opensource.cirrus.com>,
USB list <linux-usb@vger.kernel.org>
Subject: Re: [PATCH v2] usbfs: Add ioctls for runtime power management
Date: Thu, 8 Aug 2019 17:37:07 +0200 [thread overview]
Message-ID: <20190808153707.GA15091@kroah.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1908071013220.1514-100000@iolanthe.rowland.org>
On Wed, Aug 07, 2019 at 10:29:50AM -0400, Alan Stern wrote:
> It has been requested that usbfs should implement runtime power
> management, instead of forcing the device to remain at full power as
> long as the device file is open. This patch introduces that new
> feature.
>
> It does so by adding three new usbfs ioctls:
>
> USBDEVFS_FORBID_SUSPEND: Prevents the device from going into
> runtime suspend (and causes a resume if the device is already
> suspended).
>
> USBDEVFS_ALLOW_SUSPEND: Allows the device to go into runtime
> suspend. Some time may elapse before the device actually is
> suspended, depending on things like the autosuspend delay.
>
> USBDEVFS_WAIT_FOR_RESUME: Blocks until the call is interrupted
> by a signal or at least one runtime resume has occurred since
> the most recent ALLOW_SUSPEND ioctl call (which may mean
> immediately, even if the device is currently suspended). In
> the latter case, the device is prevented from suspending again
> just as if FORBID_SUSPEND was called before the ioctl returns.
>
> For backward compatibility, when the device file is first opened
> runtime suspends are forbidden. The userspace program can then allow
> suspends whenever it wants, and either resume the device directly (by
> forbidding suspends again) or wait for a resume from some other source
> (such as a remote wakeup). URBs submitted to a suspended device will
> fail or will complete with an appropriate error code.
>
> This combination of ioctls is sufficient for user programs to have
> nearly the same degree of control over a device's runtime power
> behavior as kernel drivers do.
>
> Still lacking is documentation for the new ioctls. I intend to add it
> later, after the existing documentation for the usbfs userspace API is
> straightened out into a reasonable form.
>
> Suggested-by: Mayuresh Kulkarni <mkulkarni@opensource.cirrus.com>
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
>
> ---
>
> v2: Return -EINTR instead of -ERESTARTSYS when proc_wait_for_resume()
> is interrupted by a signal.
Looks great, thanks for doing this. Now queued up.
greg k-h
prev parent reply other threads:[~2019-08-08 15:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-06 19:46 [PATCH] usbfs: Add ioctls for runtime power management Alan Stern
2019-08-07 7:37 ` Oliver Neukum
2019-08-07 14:29 ` [PATCH v2] " Alan Stern
2019-08-08 15:37 ` Greg KH [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190808153707.GA15091@kroah.com \
--to=greg@kroah.com \
--cc=linux-usb@vger.kernel.org \
--cc=mkulkarni@opensource.cirrus.com \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).