linux-kernel - Re: [RFC][PATCH] Power domains for platform bus type

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 31 Jan 2011 23:16:51 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Magnus Damm <magnus.damm@...il.com>,
	"Linux-pm mailing list" <linux-pm@...ts.linux-foundation.org>,
	Greg KH <greg@...ah.com>, LKML <linux-kernel@...r.kernel.org>,
	Kevin Hilman <khilman@...com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Len Brown <lenb@...nel.org>
Subject: Re: [RFC][PATCH] Power domains for platform bus type

On Monday, January 31, 2011, Alan Stern wrote:
> On Mon, 31 Jan 2011, Rafael J. Wysocki wrote:
> 
> > On Monday, January 31, 2011, Alan Stern wrote:
> > > On Sun, 30 Jan 2011, Rafael J. Wysocki wrote:
> > > 
> > > > > One thing about this implementation is slightly questionable.  The new
> > > > > power_domain callbacks were added to the __weak platform PM routines,
> > > > > which means they will have to be included in every overriding routine
> > > > > provided by a platform imiplementation.
> > > > > 
> > > > > Would it be better to separate these things?  Have the power_domain 
> > > > > callbacks occur in a static outer function which then calls a public 
> > > > > __weak inner function that can be overridden?
> > > > 
> > > > That certainly is a good idea, but I wasn't sure how to do that.  It looks
> > > > like I could keep the __weak functions as they are and modify
> > > > platform_dev_pm_ops instead to point to a new set of function that in turn
> > > > would call the __weak ones.  For example, the .suspend pointer in
> > > > platform_dev_pm_ops might point to a new function, say
> > > > platform_pm_full_suspend() that would call the power domain functions and
> > > > the "original" platform_pm_suspend().  Is that what you mean?
> > > 
> > > Yes.  But what about the platform_bus_set_pm_ops() interface?  Should
> > > platform-specific replacements for the pm_ops functions also include
> > > the power_domain callbacks?
> > 
> > Well, whoever uses platform_bus_set_pm_ops(), he can simply prevent power
> > domains from being used by not defining them in the first place. :-)
> 
> But what about the case where the user _does_ want to have power
> domains?

Ah, OK.  The caller of platform_bus_set_pm_ops() will replace the original
platform_dev_pm_ops with his own set of operations, so he will not see the
power domains.

> Do you want to make the replacement routines responsible for
> invoking the power-domain callbacks, or should the platform core handle
> this automatically?

Well, if someone replaces the entire platform_dev_pm_ops object, this means
that on his platform power management is substantially different from the
generic one.  In that case, IMO, he should be responsible for handling all
of the subsystem-level aspects of power management, including power domains.

Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/