From: Alan Stern <stern@rowland.harvard.edu>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: linux-pci@vger.kernel.org, USB list <linux-usb@vger.kernel.org>,
Linux PM list <linux-pm@vger.kernel.org>
Subject: Re: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)
Date: Tue, 31 Jul 2012 17:05:24 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.44L0.1207311658340.1532-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <201207312231.19505.rjw@sisk.pl>
[CC: list trimmed]
On Tue, 31 Jul 2012, Rafael J. Wysocki wrote:
> Now it occured to me that perhaps we don't need the current asynchronous
> pm_runtime_get() at all. The usefulness of it is quite questionable, because
> either we want to resume the device immediately, for which pm_runtime_get_sync()
> should be used, or we just want to bump up the usage counter, in which cases
> pm_runtime_get_noresume() should always be sufficient. I fail to see any
> particularly compelling use case for pm_runtime_get() doing an asynchronous
> resume at the moment, but perhaps that's just me.
There are indeed valid uses for pm_runtime_get(). We are forced to use
it in non-sleepable contexts when we want to resume the device as
quickly as possible. Example: a driver receives an I/O request from an
interrupt handler.
> However, I receive reports of people using pm_runtime_get() where they really
> should use pm_runtime_get_sync(), so I wonder if we can simply rename
> pm_runtime_get_sync() as pm_runtime_get() and drop the asynchronous version
> altogether?
Well, IMO the naming should have been the other way around from the
start. That is, we should have made pm_runtime_get be the synchronous
routine and pm_runtime_get_async be the asynchronous one. But it's too
late to change now.
And no, we can't get rid of the async version.
Alan Stern
next prev parent reply other threads:[~2012-07-31 21:05 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.44L0.1207241312050.1164-100000@iolanthe.rowland.org>
[not found] ` <87r4s0opck.fsf@nemi.mork.no>
2012-07-25 4:08 ` bisected regression, v3.5 -> next-20120724: PCI PM causes USB hotplug failure Bjørn Mork
2012-07-25 4:34 ` Huang Ying
2012-07-25 9:58 ` Bjørn Mork
2012-07-25 13:30 ` huang ying
2012-07-25 13:58 ` Bjørn Mork
2012-07-25 18:56 ` Rafael J. Wysocki
2012-07-25 20:02 ` Rafael J. Wysocki
2012-07-25 22:36 ` Bjørn Mork
2012-07-26 2:38 ` Huang Ying
2012-07-26 2:38 ` Huang Ying
2012-07-26 8:54 ` Huang Ying
2012-07-26 10:35 ` Bjørn Mork
2012-07-26 11:02 ` Bjørn Mork
2012-07-26 12:04 ` Bjørn Mork
2012-07-26 15:03 ` Alan Stern
2012-07-26 16:24 ` Bjørn Mork
2012-07-27 5:35 ` Huang Ying
2012-07-27 9:11 ` Bjørn Mork
2012-07-30 3:15 ` Huang Ying
2012-07-30 8:08 ` Bjørn Mork
2012-07-30 13:31 ` huang ying
2012-07-30 16:57 ` Bjørn Mork
2012-07-31 0:22 ` Huang Ying
2012-07-30 14:19 ` Alan Stern
2012-07-31 0:24 ` Huang Ying
2012-07-31 3:18 ` Huang Ying
2012-07-31 17:07 ` Alan Stern
2012-07-27 15:03 ` Alan Stern
2012-07-27 19:11 ` Rafael J. Wysocki
2012-07-27 19:39 ` Alan Stern
2012-07-27 19:54 ` Rafael J. Wysocki
2012-07-28 16:12 ` Alan Stern
2012-07-28 20:26 ` Rafael J. Wysocki
2012-07-28 21:12 ` Alan Stern
2012-07-29 13:55 ` Rafael J. Wysocki
2012-07-29 14:55 ` Alan Stern
2012-07-29 19:18 ` Rafael J. Wysocki
2012-07-31 20:31 ` Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...) Rafael J. Wysocki
2012-07-31 21:05 ` Alan Stern [this message]
2012-07-31 21:34 ` Rafael J. Wysocki
2012-07-31 21:49 ` Rafael J. Wysocki
2012-08-01 14:36 ` Alan Stern
2012-08-01 21:24 ` Rafael J. Wysocki
2012-08-02 20:16 ` Alan Stern
2012-08-02 21:26 ` Rafael J. Wysocki
2012-08-03 2:20 ` Alan Stern
2012-08-03 3:37 ` Ming Lei
2012-08-03 14:28 ` Alan Stern
2012-08-04 19:47 ` Rafael J. Wysocki
2012-08-04 20:25 ` Alan Stern
2012-08-04 20:48 ` Rafael J. Wysocki
2012-08-04 20:48 ` Alan Stern
2012-08-04 21:15 ` Rafael J. Wysocki
2012-08-04 22:13 ` Alan Stern
2012-08-05 15:26 ` Rafael J. Wysocki
2012-08-06 13:30 ` Ming Lei
2012-08-06 14:47 ` Alan Stern
2012-08-07 1:35 ` Ming Lei
2012-08-07 11:23 ` Rafael J. Wysocki
2012-08-07 15:14 ` Ming Lei
2012-08-07 15:42 ` Alan Stern
2012-08-07 16:30 ` Ming Lei
2012-08-07 20:57 ` Rafael J. Wysocki
2012-08-07 20:45 ` Rafael J. Wysocki
2012-08-08 2:02 ` Ming Lei
2012-08-08 18:42 ` Alan Stern
2012-08-08 20:16 ` Rafael J. Wysocki
2012-08-09 5:55 ` Ming Lei
2012-08-09 10:46 ` Rafael J. Wysocki
2012-08-09 10:55 ` Ming Lei
2012-08-09 19:41 ` Rafael J. Wysocki
2012-08-10 3:19 ` Ming Lei
2012-08-10 20:29 ` Rafael J. Wysocki
2012-08-08 22:27 ` Rafael J. Wysocki
2012-08-06 15:48 ` Alan Stern
2012-08-06 20:30 ` Rafael J. Wysocki
2012-08-07 12:28 ` Rafael J. Wysocki
2012-08-07 17:15 ` Alan Stern
2012-08-07 21:31 ` Rafael J. Wysocki
2012-08-03 14:05 ` Alan Stern
2012-08-04 20:08 ` Rafael J. Wysocki
2012-08-04 20:42 ` Alan Stern
2012-08-04 20:59 ` Rafael J. Wysocki
2012-08-04 19:35 ` Rafael J. Wysocki
2012-07-29 20:12 ` bisected regression, v3.5 -> next-20120724: PCI PM causes USB hotplug failure Jassi Brar
2012-07-29 21:44 ` Alan Stern
2012-07-25 19:51 ` [PATCH] PCI / PM: Fix messages printed by acpi_pci_set_power_state() Rafael J. Wysocki
2012-07-25 20:02 ` Alan Stern
2012-07-25 20:48 ` [PATCH][update] " Rafael J. Wysocki
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=Pine.LNX.4.44L0.1207311658340.1532-100000@iolanthe.rowland.org \
--to=stern@rowland.harvard.edu \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=rjw@sisk.pl \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.