From: Alan Stern <stern@rowland.harvard.edu>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Allen Yu <alleny@nvidia.com>, Pavel Machek <pavel@ucw.cz>,
Len Brown <len.brown@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
Linux-pm mailing list <linux-pm@vger.kernel.org>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] Add "rpm_not_supported" flag
Date: Wed, 2 Jul 2014 10:27:06 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.44L0.1407021002380.874-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <3135210.ApPvOPL31q@vostro.rjw.lan>
On Wed, 2 Jul 2014, Rafael J. Wysocki wrote:
> > Then you have no other objections to the patch?
>
> My concern still is that it will be confusing, because people won't read the
> documentation carefully enough and will confuse "runtime PM never used" with
> "hardware can't do PM". I'm not sure how to make that more clear, though.
I could emphasize that distinction a little more strongly in the
documentation.
> Also we have the no_callbacks flag and I wonder if/how it is related to the
> new one. Do we still need both?
They mean different things. The no_callbacks flag is used when we want
the PM core to think the device can be in RPM_SUSPENDED at times (it is
"logically suspended"). rpm_not_supported is used when we want the PM
core to think the device must always be in RPM_ACTIVE.
> In addition to that, I think that "hardware can't do PM" should apply to the
> handling of system suspend resume too.
Maybe. For the use case Dan Williams and I are working on, it doesn't
matter; for other cases it might matter. That's why I named the flag
"rpm_not_supported" -- it applies specifically to runtime PM, not
system PM.
Here's a brief summary of the story behind this patch...
At one point, I suggested to Dan that instead of doing something
special for these devices, we could simply have the runtime_suspend()
routine always return -EBUSY. He didn't like that idea because then
the user would see the device was never powering down but would have no
idea why. The rpm_not_supported flag provides this information to the
user by causing the power/runtime_status attribute to say "not
supported". (Although to be entirely fair, we could just put a message
in the kernel log during probe if the hardware doesn't support runtime
suspend.)
Instead, Dan introduced a messy PM QoS mechanism in commit
e3d105055525. I didn't like that approach, but Greg merged it before I
objected.
Do you have any suggestions?
Alan Stern
next prev parent reply other threads:[~2014-07-02 14:27 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-14 10:03 [PATCH 1/1] PM / Runtime: let rpm_resume fail if rpm disabled and device suspended Allen Yu
2014-06-14 10:03 ` Allen Yu
2014-06-14 14:32 ` Alan Stern
2014-06-14 14:32 ` Alan Stern
2014-06-16 3:03 ` Allen Yu
2014-06-16 14:43 ` Alan Stern
2014-06-16 17:40 ` Alan Stern
2014-06-16 17:40 ` Alan Stern
2014-06-16 21:29 ` Rafael J. Wysocki
2014-06-17 14:11 ` Alan Stern
2014-06-17 14:11 ` Alan Stern
2014-06-17 20:26 ` Rafael J. Wysocki
2014-06-17 20:37 ` Rafael J. Wysocki
2014-06-17 20:46 ` Rafael J. Wysocki
2014-06-18 15:30 ` Alan Stern
2014-06-18 15:30 ` Alan Stern
2014-06-18 23:57 ` Rafael J. Wysocki
2014-06-19 8:23 ` Allen Yu
2014-06-19 8:23 ` Allen Yu
2014-06-19 13:55 ` Rafael J. Wysocki
2014-06-19 14:34 ` Allen Yu
2014-06-19 14:34 ` Allen Yu
2014-06-20 14:04 ` Rafael J. Wysocki
2014-06-19 14:56 ` Alan Stern
2014-06-19 19:25 ` Kevin Hilman
2014-06-19 19:25 ` Kevin Hilman
2014-06-19 20:13 ` Alan Stern
2014-06-20 13:20 ` Rafael J. Wysocki
2014-06-20 14:48 ` Alan Stern
2014-06-20 21:34 ` Kevin Hilman
2014-06-20 21:34 ` Kevin Hilman
2014-06-22 13:40 ` Rafael J. Wysocki
2014-06-22 13:24 ` Rafael J. Wysocki
2014-06-20 21:31 ` Kevin Hilman
2014-06-20 21:31 ` Kevin Hilman
2014-06-21 13:34 ` Alan Stern
2014-06-22 13:35 ` Rafael J. Wysocki
2014-06-23 18:57 ` Kevin Hilman
2014-06-23 18:57 ` Kevin Hilman
2014-06-19 14:34 ` Alan Stern
2014-06-19 14:34 ` Alan Stern
2014-06-20 13:33 ` Rafael J. Wysocki
2014-06-20 14:43 ` Alan Stern
2014-06-20 14:43 ` Alan Stern
2014-06-22 13:21 ` Rafael J. Wysocki
2014-06-22 16:45 ` Alan Stern
2014-06-22 16:45 ` Alan Stern
2014-06-24 23:38 ` Rafael J. Wysocki
2014-06-27 18:27 ` [RFC] Add "rpm_not_supported" flag Alan Stern
2014-06-27 19:22 ` Greg Kroah-Hartman
2014-06-27 20:11 ` Alan Stern
2014-06-27 20:50 ` Greg Kroah-Hartman
2014-06-28 15:32 ` Alan Stern
2014-06-30 13:52 ` Rafael J. Wysocki
2014-06-30 14:42 ` Alan Stern
2014-07-01 23:18 ` Rafael J. Wysocki
2014-07-02 14:27 ` Alan Stern [this message]
2014-07-02 17:56 ` Greg Kroah-Hartman
2014-07-03 21:16 ` Rafael J. Wysocki
2014-07-03 21:17 ` Alan Stern
2014-07-16 22:40 ` Rafael J. Wysocki
2014-07-16 23:03 ` Greg Kroah-Hartman
2014-07-16 23:27 ` Rafael J. Wysocki
2014-07-17 14:27 ` Alan Stern
2014-07-18 0:48 ` 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.1407021002380.874-100000@iolanthe.rowland.org \
--to=stern@rowland.harvard.edu \
--cc=alleny@nvidia.com \
--cc=dan.j.williams@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rjw@rjwysocki.net \
/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.