On Thu, 27 Feb 2014, Ulf Hansson wrote:

On 27 February 2014 17:22, Alan Stern [off-list ref] wrote:

quoted

On Thu, 27 Feb 2014, Ulf Hansson wrote:

quoted

quoted

A reasonable compromise would be to define the macro, and then use it
in those three new functions (and nowhere else).

Okay, let me send a v3 that tries this approach then.

quoted

The existing rpm_idle, rpm_suspend, and rpm_resume routines should then
be changed to use the new functions.  And of course, the new functions
could be called directly by subsystems or PM domains.

Not sure we should export these functions as a part of this patchset.
Would it not be preferred, to first see if there are any that needs
it?

I don't understand.  V2 of the patchset exports
pm_runtime_force_suspend and pm_runtime_force_resume.  Why wouldn't you
want to export them in V3?

There are some confusion here. :-)  pm_runtime_force_suspend|resume()
surely need to be exported, but that's "patch v2 2/8".

I think we were debating whether this patch "patch v2 1/8" should use
a macro to walk the ladder to fetch the runtime PM callback - or if we
should implement a three c-functions to handle it. I prefer to keep
this patch as is, thus using the macro.

But you're going to expand the macro (say, the version that handles
runtime_resume callbacks) in two places: rpm_resume and
pm_runtime_force_resume.  That's inefficient.  The macro generates
fairly complicated code, and so it should be expanded in only one
place: a single new function.  The new function can be called by both
rpm_resume and pm_runtime_force_resume.

In fact, from comparing those two routines, it looks like the new
function could include a little more than just the macro expansion.

Alan Stern