Re: [PATCH 1/4] PM: Drop the SET_PM_RUNTIME_PM_OPS() macro

[Rafael J. Wysocki]

On Thursday, December 04, 2014 11:04:20 AM Ulf Hansson wrote:
> On 3 December 2014 at 23:51, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote:
> > On Wednesday, December 03, 2014 03:15:49 PM Ulf Hansson wrote:
> >> On 27 November 2014 at 01:38, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote:
> >> > From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> >> >
> >> > The SET_PM_RUNTIME_PM_OPS() and SET_RUNTIME_PM_OPS() macros are
> >> > identical except that one of them is not empty for CONFIG_PM set,
> >> > while the other one is not empty for CONFIG_PM_RUNTIME set,
> >> > respectively.
> >> >
> >> > However, after commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if
> >> > PM_SLEEP is selected) PM_RUNTIME is always set if PM is set, so one
> >> > of these macros is now redundant.
> >> >
> >> > For this reason, drop SET_PM_RUNTIME_PM_OPS() and replace it with
> >> > SET_RUNTIME_PM_OPS() everywhere.
> >>
> >> Hi Rafael,
> >>
> >> Apparently, I have queued an mmc patch in my mmc tree, which means one
> >> mmc driver starts using the SET_PM_RUNTIME_PM_OPS macro. It should
> >> cause a build error in linux-next with @subject patch.
> >>
> >> I have shared that patch through an immutable branch, I have also
> >> checked potential conflicts and it shouldn't be any problems to pull
> >> that in to your tree. Then you can fix $subject patch by also
> >> converting the mmc driver to use SET_RUNTIME_PM_OPS macro.
> >>
> >> The branch is available at:
> >> git://git.linaro.org/people/ulf.hansson/mmc.git mmc_for_linux_pm
> >
> > Thanks for letting me know!
> >
> > What about adding the following line to the $subject patch instead:
> >
> > #define SET_PM_RUNTIME_PM_OPS   SET_RUNTIME_PM_OPS
> >
> > and fixing things up when all has been merged?
> 
> That's an option.
> 
> On the other hand we will have a window of new users of
> SET_PM_RUNTIME_PM_OPS, during the next release cycle. Or are you
> saying that we should send fixes for the rc which takes care of the
> removal of it?

That is my plan.

It is quite usual for new users of stuff being reworked to appear at the
same time and that can always be addressed by doing a second round of
replacements after the merge window.

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/