From: Greg KH <greg@kroah.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Grant Likely <grant.likely@secretlab.ca>,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
LKML <linux-kernel@vger.kernel.org>,
Linux-pm mailing list <linux-pm@lists.linux-foundation.org>
Subject: Re: [RFC][PATCH 2/2] PM: Make system-wide PM and runtime PM handle subsystems consistently
Date: Thu, 17 Feb 2011 09:04:41 -0800 [thread overview]
Message-ID: <20110217170441.GA31809@kroah.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1102170951330.2153-100000@iolanthe.rowland.org>
On Thu, Feb 17, 2011 at 09:55:46AM -0500, Alan Stern wrote:
> On Thu, 17 Feb 2011, Rafael J. Wysocki wrote:
>
> > > > Apart from this I think the order of checks introduced by the $subject patch
> > > > should be:
> > > > (1) If dev->class != NULL and dev->class->pm != NULL, use dev->class,
> > > > or otherwise
> > > > (2) if dev->type != NULL and dev->type->pm != NULL, use dev->type,
> > > > or otherwise
> > > > (3) use dev->bus (if present).
> > > > as that would allow classes and device types to override bus type PM
> > > > callbacks if they wish to.
> > >
> > > I haven't heard of any device types being present on more than one kind
> > > of bus, so it makes sense for device types to override bus types.
> >
> > OK
> >
> > > But I'm not so sure about the priority we should give to classes. On the
> > > other hand, if no classes define a dev_pm_ops then of course it doesn't
> > > matter.
> >
> > The change will also affect classes that provide "legacy" suspend-resume
> > (if there are any, which I'm totally unsure of).
> >
> > Anyway, I think we need to choose one ordering. :-)
> >
> > What about type / bus / class , then?
>
> I really don't know. Somebody who has more experience with device
> class implementations should answer.
>
> Greg, any ideas?
>
> To recap: The issue is how to handle multiple PM callbacks. Since the
> bus type, device type, and device class may all have their own
> callbacks, Rafael has decided the best approach is to prioritize them
> and invoke only the highest-priority callback. But what priority order
> should we use?
I think we should do it in the following order:
device type
device class
device bus
for the reasons that a device itself could override the default class
and bus information if it "knows" it is special. After that, the class
of the device holds a lot of information about what is going on with the
logic involved (i.e. network stuff), and lastly, the bus knows some
default hardware information.
Sound reasonable?
I think that follows the default we have today, right?
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <greg@kroah.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
Linux-pm mailing list <linux-pm@lists.linux-foundation.org>,
Kevin Hilman <khilman@ti.com>,
Grant Likely <grant.likely@secretlab.ca>,
LKML <linux-kernel@vger.kernel.org>,
Magnus Damm <magnus.damm@gmail.com>, Len Brown <lenb@kernel.org>,
Mark Brown <broonie@opensource.wolfsonmicro.com>
Subject: Re: [RFC][PATCH 2/2] PM: Make system-wide PM and runtime PM handle subsystems consistently
Date: Thu, 17 Feb 2011 09:04:41 -0800 [thread overview]
Message-ID: <20110217170441.GA31809@kroah.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1102170951330.2153-100000@iolanthe.rowland.org>
On Thu, Feb 17, 2011 at 09:55:46AM -0500, Alan Stern wrote:
> On Thu, 17 Feb 2011, Rafael J. Wysocki wrote:
>
> > > > Apart from this I think the order of checks introduced by the $subject patch
> > > > should be:
> > > > (1) If dev->class != NULL and dev->class->pm != NULL, use dev->class,
> > > > or otherwise
> > > > (2) if dev->type != NULL and dev->type->pm != NULL, use dev->type,
> > > > or otherwise
> > > > (3) use dev->bus (if present).
> > > > as that would allow classes and device types to override bus type PM
> > > > callbacks if they wish to.
> > >
> > > I haven't heard of any device types being present on more than one kind
> > > of bus, so it makes sense for device types to override bus types.
> >
> > OK
> >
> > > But I'm not so sure about the priority we should give to classes. On the
> > > other hand, if no classes define a dev_pm_ops then of course it doesn't
> > > matter.
> >
> > The change will also affect classes that provide "legacy" suspend-resume
> > (if there are any, which I'm totally unsure of).
> >
> > Anyway, I think we need to choose one ordering. :-)
> >
> > What about type / bus / class , then?
>
> I really don't know. Somebody who has more experience with device
> class implementations should answer.
>
> Greg, any ideas?
>
> To recap: The issue is how to handle multiple PM callbacks. Since the
> bus type, device type, and device class may all have their own
> callbacks, Rafael has decided the best approach is to prioritize them
> and invoke only the highest-priority callback. But what priority order
> should we use?
I think we should do it in the following order:
device type
device class
device bus
for the reasons that a device itself could override the default class
and bus information if it "knows" it is special. After that, the class
of the device holds a lot of information about what is going on with the
logic involved (i.e. network stuff), and lastly, the bus knows some
default hardware information.
Sound reasonable?
I think that follows the default we have today, right?
thanks,
greg k-h
next prev parent reply other threads:[~2011-02-17 17:04 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-30 0:07 [RFC][PATCH] Power domains for platform bus type Rafael J. Wysocki
2011-01-30 16:03 ` Alan Stern
2011-01-30 22:39 ` Rafael J. Wysocki
2011-01-31 15:01 ` Alan Stern
2011-01-31 15:01 ` Alan Stern
2011-01-31 18:09 ` Rafael J. Wysocki
2011-01-31 18:09 ` Rafael J. Wysocki
2011-01-31 19:45 ` Alan Stern
2011-01-31 19:45 ` Alan Stern
2011-01-31 22:16 ` Rafael J. Wysocki
2011-01-31 22:16 ` Rafael J. Wysocki
2011-01-31 22:26 ` Grant Likely
2011-01-31 22:26 ` Grant Likely
2011-01-31 22:44 ` Kevin Hilman
2011-01-31 22:44 ` Kevin Hilman
2011-01-31 23:01 ` Rafael J. Wysocki
2011-01-31 23:01 ` Rafael J. Wysocki
2011-01-30 22:39 ` Rafael J. Wysocki
2011-01-30 16:03 ` Alan Stern
2011-01-31 12:05 ` Mark Brown
2011-01-31 12:05 ` Mark Brown
2011-01-31 22:59 ` Grant Likely
2011-01-31 22:59 ` Grant Likely
2011-01-31 23:10 ` Rafael J. Wysocki
2011-01-31 23:10 ` Rafael J. Wysocki
2011-01-31 23:43 ` Kevin Hilman
2011-01-31 23:43 ` Kevin Hilman
2011-02-01 3:18 ` Grant Likely
2011-02-01 10:58 ` Rafael J. Wysocki
2011-02-01 10:58 ` Rafael J. Wysocki
2011-02-01 16:48 ` Kevin Hilman
2011-02-01 18:39 ` Rafael J. Wysocki
2011-02-01 18:39 ` Rafael J. Wysocki
2011-02-12 22:12 ` [RFC][PATCH 0/2] PM: Core power management modifications Rafael J. Wysocki
2011-02-12 22:13 ` [RFC][PATCH 1/2] PM: Add support for device power domains Rafael J. Wysocki
2011-02-12 22:13 ` Rafael J. Wysocki
2011-02-14 16:12 ` Alan Stern
2011-02-14 22:34 ` Rafael J. Wysocki
2011-02-14 22:34 ` Rafael J. Wysocki
2011-02-15 3:01 ` Alan Stern
2011-02-15 21:40 ` Rafael J. Wysocki
2011-02-15 21:40 ` Rafael J. Wysocki
2011-02-15 3:01 ` Alan Stern
2011-02-15 7:28 ` Magnus Damm
2011-02-15 23:12 ` Rafael J. Wysocki
2011-02-15 23:12 ` Rafael J. Wysocki
2011-02-15 7:28 ` Magnus Damm
2011-02-14 16:12 ` Alan Stern
2011-02-15 18:23 ` Kevin Hilman
2011-02-15 18:23 ` Kevin Hilman
2011-02-12 22:14 ` [RFC][PATCH 2/2] PM: Make system-wide PM and runtime PM handle subsystems consistently Rafael J. Wysocki
2011-02-14 16:25 ` Alan Stern
2011-02-14 16:25 ` Alan Stern
2011-02-14 22:35 ` Rafael J. Wysocki
2011-02-14 22:35 ` Rafael J. Wysocki
2011-02-16 12:24 ` Rafael J. Wysocki
2011-02-16 14:57 ` Alan Stern
2011-02-16 14:57 ` Alan Stern
2011-02-16 21:47 ` Rafael J. Wysocki
2011-02-16 21:47 ` Rafael J. Wysocki
2011-02-16 22:23 ` Alan Stern
2011-02-16 23:45 ` Rafael J. Wysocki
2011-02-16 23:45 ` Rafael J. Wysocki
2011-02-17 14:55 ` Alan Stern
2011-02-17 17:04 ` Greg KH [this message]
2011-02-17 17:04 ` Greg KH
2011-02-17 22:16 ` Rafael J. Wysocki
2011-02-17 22:16 ` Rafael J. Wysocki
2011-02-17 23:54 ` [PATCH] PM: Make system-wide PM and runtime PM treat " R. J. Wysocki
2011-02-18 19:22 ` Greg KH
2011-02-18 19:22 ` Greg KH
2011-02-18 20:14 ` Rafael J. Wysocki
2011-02-18 20:14 ` Rafael J. Wysocki
2011-02-17 23:54 ` R. J. Wysocki
2011-02-17 14:55 ` [RFC][PATCH 2/2] PM: Make system-wide PM and runtime PM handle " Alan Stern
2011-02-16 22:23 ` Alan Stern
2011-02-16 12:24 ` Rafael J. Wysocki
2011-02-15 18:10 ` Kevin Hilman
2011-02-15 18:10 ` Kevin Hilman
2011-02-15 19:48 ` Grant Likely
2011-02-15 19:48 ` Grant Likely
2011-02-12 22:14 ` Rafael J. Wysocki
2011-02-12 22:12 ` [RFC][PATCH 0/2] PM: Core power management modifications Rafael J. Wysocki
2011-02-01 16:48 ` [RFC][PATCH] Power domains for platform bus type Kevin Hilman
2011-02-01 3:18 ` Grant Likely
2011-02-01 3:40 ` Alan Stern
2011-02-01 3:40 ` Alan Stern
2011-01-31 23:16 ` Kevin Hilman
2011-01-31 23:16 ` Kevin Hilman
2011-01-31 23:23 ` Grant Likely
2011-01-31 23:23 ` Grant Likely
2011-02-01 0:17 ` Kevin Hilman
2011-02-01 10:52 ` Rafael J. Wysocki
2011-02-01 10:52 ` Rafael J. Wysocki
2011-02-01 0:17 ` Kevin Hilman
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=20110217170441.GA31809@kroah.com \
--to=greg@kroah.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=grant.likely@secretlab.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--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 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.