mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: huang ying <huang.ying.caritas@gmail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Huang Ying <ying.huang@intel.com>,
	ming.m.lin@intel.com, linux-kernel@vger.kernel.org,
	linux-pm@vger.kernel.org, Zheng Yan <zheng.z.yan@intel.com>
Subject: Re: [RFC v2 1/5] PM, Runtime, Add power_must_be_on flag
Date: Mon, 7 May 2012 22:37:58 +0200	[thread overview]
Message-ID: <201205072237.58753.rjw@sisk.pl> (raw)
In-Reply-To: <CAC=cRTPfkw5tQHLbACyJey1MKV=fTZiV_NqKKicgksXEF5QRpQ@mail.gmail.com>

On Saturday, May 05, 2012, huang ying wrote:
> On Sat, May 5, 2012 at 3:50 AM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> > On Fri, May 4, 2012 at 2:13 AM, Huang Ying <ying.huang@intel.com> wrote:
> >> --- a/include/linux/pm.h
> >> +++ b/include/linux/pm.h
> >> @@ -536,6 +536,7 @@ struct dev_pm_info {
> >>        unsigned int            irq_safe:1;
> >>        unsigned int            use_autosuspend:1;
> >>        unsigned int            timer_autosuspends:1;
> >> +       unsigned int            power_must_be_on:1;
> >>        enum rpm_request        request;
> >>        enum rpm_status         runtime_status;
> >>        int                     runtime_error;
> >
> > It's a little weird to just add the field, with no users.  Would it
> > make sense to pull out the bits of patch 5 that use this and combine
> > them into a single smaller patch?
> 
> This patch is needed by some other subsystem too, such as ZPODD
> support in following patchset:
> 
> https://lkml.org/lkml/2012/3/28/23
> 
> The original plan is to merge this into linux-pm.git firstly, then
> merge various usage of this flag into various subsystem git tree.
> That will make cross-tree merging a little easier.  Is it possible?
> 
> > But see related comments there; it
> > might be safer to have a function that computes this whenever you need
> > it instead of caching the value.
> 
> This flag may be used (or calculated if implemented as a function)
> when device is in suspended state.  Reason is as follow from the
> changelog of this patch.
> 
> "
> In general, whether to put a device into power off state should be
> decided by the driver of the device, but for some buses, whether to
> put a device into power off state may be done by the parent of the
> device.  For example, a PCIe end point device may be put into power
> off state by the PCIe port connected to it.
> "
> 
> If all devices can calculate "power_must_be_on" when it is in
> suspended state, then this will be a design choice.
> 
> Hi, Rafael,
> 
> What do you think about the idea to replace .power_must_be_on with a
> function

That looks like a static characteristics of a device (ie. one that's not going
to change at run time), so it seems better to use a flag for it.

> (maybe add a new callback in pm_ops)?

Please don't do that.  We have many of them already.

Thanks,
Rafael

  reply	other threads:[~2012-05-07 20:33 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-04  8:13 [RFC v2 0/5] PCIe, Add PCIe runtime D3cold support Huang Ying
2012-05-04  8:13 ` [RFC v2 1/5] PM, Runtime, Add power_must_be_on flag Huang Ying
2012-05-04 19:37   ` Rafael J. Wysocki
2012-05-05  5:15     ` huang ying
2012-05-07 20:33       ` Rafael J. Wysocki
2012-05-04 19:50   ` Bjorn Helgaas
2012-05-05  5:59     ` huang ying
2012-05-07 20:37       ` Rafael J. Wysocki [this message]
2012-05-04  8:13 ` [RFC v2 2/5] PM, Add sysfs file power_off to control device power off policy Huang Ying
2012-05-04 19:33   ` Rafael J. Wysocki
2012-05-05  6:29     ` huang ying
2012-05-07 20:53       ` Rafael J. Wysocki
2012-05-08  1:44         ` Huang Ying
2012-05-08 21:34           ` Rafael J. Wysocki
2012-05-09  6:46             ` Huang Ying
2012-05-09 10:38               ` Rafael J. Wysocki
2012-05-10  0:55                 ` Huang Ying
2012-05-10 14:48                   ` Alan Stern
2012-05-10 19:03                     ` Rafael J. Wysocki
2012-05-04 19:50   ` Bjorn Helgaas
2012-05-04 21:00     ` Rafael J. Wysocki
2012-05-05  6:36     ` huang ying
2012-05-04  8:13 ` [RFC v2 3/5] PCIe, Add runtime PM support to PCIe port Huang Ying
2012-05-04 19:43   ` Rafael J. Wysocki
2012-05-05  6:46     ` huang ying
2012-05-07 21:00       ` Rafael J. Wysocki
2012-05-11  7:57         ` Huang Ying
2012-05-11 18:44           ` Rafael J. Wysocki
2012-05-04 19:50   ` Bjorn Helgaas
2012-05-04 20:55     ` Rafael J. Wysocki
2012-05-05  6:54       ` huang ying
2012-05-07 21:06         ` Rafael J. Wysocki
2012-05-05  6:53     ` huang ying
2012-05-04  8:13 ` [RFC v2 4/5] ACPI, PM, Specify lowest allowed state for device sleep state Huang Ying
2012-05-04 20:10   ` Rafael J. Wysocki
2012-05-05  7:25     ` huang ying
2012-05-07 21:15       ` Rafael J. Wysocki
2012-05-08  1:49         ` Huang Ying
2012-05-04  8:13 ` [RFC v2 5/5] PCIe, Add PCIe runtime D3cold support Huang Ying
2012-05-04 19:51   ` Bjorn Helgaas
2012-05-05  7:34     ` huang ying
2012-05-04 20:50   ` Rafael J. Wysocki
2012-05-05  8:08     ` huang ying
2012-05-07 21:22       ` Rafael J. Wysocki
2012-05-08  2:22         ` Huang Ying
2012-05-08  8:34           ` Huang Ying
2012-05-10 19:28             ` 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=201205072237.58753.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=bhelgaas@google.com \
    --cc=huang.ying.caritas@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=ming.m.lin@intel.com \
    --cc=ying.huang@intel.com \
    --cc=zheng.z.yan@intel.com \
    /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

Powered by JetHome