The following patch series introduces a marker for power management functions
and data. This this marker, #ifdef CONFIG_PM and #ifdef CONFIG_PM_SLEEP
can be removed from most of the code. This ensures that the conditional code
still compiles but is not included in the object file.
As a side effect, drivers declaring struct dev_pm_ops unconditionally
get a bit smaller if CONFIG_PM_SLEEP is not configured.
The first patch in the series introduces the marker, the following
two patches introduce the marker in two drivers to demonstrate its use.
The patch series depends on the "PM: Add pm_ops_ptr() macro" patch
submitted by Jingoo Han.
On Thu, 9 May 2013, Guenter Roeck wrote:
> The following patch series introduces a marker for power management functions
> and data. This this marker, #ifdef CONFIG_PM and #ifdef CONFIG_PM_SLEEP
> can be removed from most of the code. This ensures that the conditional code
> still compiles but is not included in the object file.
>
> As a side effect, drivers declaring struct dev_pm_ops unconditionally
> get a bit smaller if CONFIG_PM_SLEEP is not configured.
What about code that depends on CONFIG_PM_RUNTIME? Or code that
depends on CONFIG_PM_SLEEP but not on CONFIG_PM_RUNTIME?
Alan Stern
On Thu, May 09, 2013 at 01:38:36PM -0400, Alan Stern wrote:
> On Thu, 9 May 2013, Guenter Roeck wrote:
>
> > The following patch series introduces a marker for power management functions
> > and data. This this marker, #ifdef CONFIG_PM and #ifdef CONFIG_PM_SLEEP
> > can be removed from most of the code. This ensures that the conditional code
> > still compiles but is not included in the object file.
> >
> > As a side effect, drivers declaring struct dev_pm_ops unconditionally
> > get a bit smaller if CONFIG_PM_SLEEP is not configured.
>
> What about code that depends on CONFIG_PM_RUNTIME? Or code that
> depends on CONFIG_PM_SLEEP but not on CONFIG_PM_RUNTIME?
>
Should we also introduce __pm_sleep and __pm_runtime ?
Thanks,
Guenter
On Thu, 9 May 2013, Guenter Roeck wrote:
> On Thu, May 09, 2013 at 01:38:36PM -0400, Alan Stern wrote:
> > On Thu, 9 May 2013, Guenter Roeck wrote:
> >
> > > The following patch series introduces a marker for power management functions
> > > and data. This this marker, #ifdef CONFIG_PM and #ifdef CONFIG_PM_SLEEP
> > > can be removed from most of the code. This ensures that the conditional code
> > > still compiles but is not included in the object file.
> > >
> > > As a side effect, drivers declaring struct dev_pm_ops unconditionally
> > > get a bit smaller if CONFIG_PM_SLEEP is not configured.
> >
> > What about code that depends on CONFIG_PM_RUNTIME? Or code that
> > depends on CONFIG_PM_SLEEP but not on CONFIG_PM_RUNTIME?
> >
> Should we also introduce __pm_sleep and __pm_runtime ?
If you want to implement this correctly, I think you have to.
As for whether the additional complication is desirable ... I'll leave
that up to Rafael to decide.
Alan Stern
On Thursday, May 09, 2013 02:31:46 PM Alan Stern wrote:
> On Thu, 9 May 2013, Guenter Roeck wrote:
>
> > On Thu, May 09, 2013 at 01:38:36PM -0400, Alan Stern wrote:
> > > On Thu, 9 May 2013, Guenter Roeck wrote:
> > >
> > > > The following patch series introduces a marker for power management functions
> > > > and data. This this marker, #ifdef CONFIG_PM and #ifdef CONFIG_PM_SLEEP
> > > > can be removed from most of the code. This ensures that the conditional code
> > > > still compiles but is not included in the object file.
> > > >
> > > > As a side effect, drivers declaring struct dev_pm_ops unconditionally
> > > > get a bit smaller if CONFIG_PM_SLEEP is not configured.
> > >
> > > What about code that depends on CONFIG_PM_RUNTIME? Or code that
> > > depends on CONFIG_PM_SLEEP but not on CONFIG_PM_RUNTIME?
> > >
> > Should we also introduce __pm_sleep and __pm_runtime ?
>
> If you want to implement this correctly, I think you have to.
>
> As for whether the additional complication is desirable ... I'll leave
> that up to Rafael to decide.
Well, if that had been so easy to do, we would have done it already before.
I think that we first should try to combine PM_SLEEP with PM_RUNTIME (plus
some other power management options related to CPU PM) and then introduce
something like __pm. Otherwise, it's going to be a mess.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
On Thursday, May 09, 2013 10:09:23 AM Guenter Roeck wrote:
> The following patch series introduces a marker for power management functions
> and data. This this marker, #ifdef CONFIG_PM and #ifdef CONFIG_PM_SLEEP
> can be removed from most of the code. This ensures that the conditional code
> still compiles but is not included in the object file.
>
> As a side effect, drivers declaring struct dev_pm_ops unconditionally
> get a bit smaller if CONFIG_PM_SLEEP is not configured.
>
> The first patch in the series introduces the marker, the following
> two patches introduce the marker in two drivers to demonstrate its use.
>
> The patch series depends on the "PM: Add pm_ops_ptr() macro" patch
> submitted by Jingoo Han.
What about CCing a PM core maintainer?
Please see my reply to Alan Stern for my opinion.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
On Thu, May 09, 2013 at 09:15:00PM +0200, Rafael J. Wysocki wrote:
> On Thursday, May 09, 2013 10:09:23 AM Guenter Roeck wrote:
> > The following patch series introduces a marker for power management functions
> > and data. This this marker, #ifdef CONFIG_PM and #ifdef CONFIG_PM_SLEEP
> > can be removed from most of the code. This ensures that the conditional code
> > still compiles but is not included in the object file.
> >
> > As a side effect, drivers declaring struct dev_pm_ops unconditionally
> > get a bit smaller if CONFIG_PM_SLEEP is not configured.
> >
> > The first patch in the series introduces the marker, the following
> > two patches introduce the marker in two drivers to demonstrate its use.
> >
> > The patch series depends on the "PM: Add pm_ops_ptr() macro" patch
> > submitted by Jingoo Han.
>
> What about CCing a PM core maintainer?
>
Actually, that was the idea. Somehow my send script got screwed up.
No idea what happened. Sorry for that.
Guenter