linux-kernel - Re: [PATCH/RFC 0/6] ARM: runtime PM: consolidate runtime PM implementations

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:	Fri, 8 Apr 2011 00:31:23 +0200
From:	"Rafael J. Wysocki" <rjw@...e.com>
To:	Kevin Hilman <khilman@...com>
Cc:	linux-arm-kernel@...ts.infradead.org, linux-omap@...r.kernel.org,
	linux-sh@...r.kernel.org, linux-kernel@...r.kernel.org,
	Magnus Damm <magnus.damm@...il.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	"Greg Kroah-Hartman" <gregkh@...e.de>,
	"Linux-pm mailing list" <linux-pm@...ts.linux-foundation.org>,
	Paul Mundt <lethal@...ux-sh.org>
Subject: Re: [PATCH/RFC 0/6] ARM: runtime PM: consolidate runtime PM implementations

On Thursday, April 07, 2011, Kevin Hilman wrote:
> Kevin Hilman <khilman@...com> writes:
> 
> [...]
> 
> > Replacing the PM ops for all devices was done on OMAP and SH-mobile
> > because that was the only approach we had.  Now that we have device
> > power domains (thanks Rafael!), we can be more selective about which
> > devices to apply them to.
> >
> > Note that my RFC patch/series did not do the selective part of deciding
> > which devices to override and which ones not to, that part will be
> > platform specific.  
> 
> Actually, thinking about this a little more, my patch actually does
> select only relevant devices, and not *all* platform devices.
> 
> In my patch, the device power domain pointers are only added for devices
> where a clk_get() actually succeeds.  In the original version, the
> runtime PM hooks are overridden for *all* platform devices, but ones
> that have no clock (or where clk_get() failed) have the additional
> overhead of still calling the custom PM ops, but the custom ops have
> nothing to do.

As I wrote in another message to Grant, the problem basically is that
the platform bus type behavior is not the desirable one.  Namely, I don't
generally want device driver callbacks to be invoked until we know that
power will be removed from the devices.  However, the platform bus type
executes driver callbacks automatically if they exist.  This currently is
unavoidable, because power domain callbacks are executed in addition to and
not instead the bus type callbacks.

We've discussed that a bit at the LF Collab Summit with Grant and Paul and
the conclusion is that to address this particular problem we'll need to change
the core so that if there is a power domain for the given device, the
power domain callbacks will be executed first and if they return a specific
error code, the core will execute the bus type callbacks.  For devices that
don't belong to any power domain, the bus type callbacks will be executed
(which is the current behavior).

I'm going to post a patch along these lines early next week.  Then, we
can simply move the management of device clocks, the execution of device
driver callbacks and the power removal into power domain callbacks.

At that point it may be possible to share some code between shmobile and
OMAP, but I'm not sure yet how much of the code may be shared and it what
way exactly.

Thanks,
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/