Messages in this thread | | | Date | Sun, 02 Oct 2022 12:18:00 +0100 | From | Paul Cercueil <> | Subject | Re: [PATCH v2 01/30] pm: Improve EXPORT_*_DEV_PM_OPS macros |
| |
Le sam., oct. 1 2022 at 18:01:30 +0100, Jonathan Cameron <jic23@kernel.org> a écrit : > On Mon, 26 Sep 2022 15:35:35 +0200 > "Rafael J. Wysocki" <rafael@kernel.org> wrote: > >> On Mon, Sep 26, 2022 at 3:27 PM Paul Cercueil >> <paul@crapouillou.net> wrote: >> > >> > Hi, >> > >> > Le lun., sept. 26 2022 at 14:00:52 +0200, Rafael J. Wysocki >> > <rafael@kernel.org> a écrit : >> > > On Sun, Sep 25, 2022 at 4:52 PM Jonathan Cameron >> <jic23@kernel.org> >> > > wrote: >> > >> >> > >> On Thu, 25 Aug 2022 23:42:53 +0100 >> > >> Paul Cercueil <paul@crapouillou.net> wrote: >> > >> >> > >> > Hi Rafael, >> > >> > >> > >> > Le mar., août 23 2022 at 19:47:57 +0200, Rafael J. Wysocki >> > >> > <rafael@kernel.org> a écrit : >> > >> > > On Mon, Aug 8, 2022 at 7:41 PM Paul Cercueil >> > >> <paul@crapouillou.net> >> > >> > > wrote: >> > >> > >> >> > >> > >> Update the _EXPORT_DEV_PM_OPS() internal macro. It was >> not >> > >> used >> > >> > >> anywhere >> > >> > >> outside pm.h and pm_runtime.h, so it is safe to update >> it. >> > >> > >> >> > >> > >> Before, this macro would take a few parameters to be >> used as >> > >> sleep >> > >> > >> and >> > >> > >> runtime callbacks. This made it unsuitable to use with >> > >> different >> > >> > >> callbacks, for instance the "noirq" ones. >> > >> > >> >> > >> > >> It is now semantically different: instead of creating a >> > >> > >> conditionally >> > >> > >> exported dev_pm_ops structure, it only contains part of >> the >> > >> > >> definition. >> > >> > >> >> > >> > >> This macro should however never be used directly (hence >> the >> > >> trailing >> > >> > >> underscore). Instead, the following four macros are >> provided: >> > >> > >> - EXPORT_DEV_PM_OPS(name) >> > >> > >> - EXPORT_GPL_DEV_PM_OPS(name) >> > >> > >> - EXPORT_NS_DEV_PM_OPS(name, ns) >> > >> > >> - EXPORT_NS_GPL_DEV_PM_OPS(name, ns) >> > >> > >> >> > >> > >> For instance, it is now possible to conditionally >> export noirq >> > >> > >> suspend/resume PM functions like this: >> > >> > >> >> > >> > >> EXPORT_GPL_DEV_PM_OPS(foo_pm_ops) = { >> > >> > >> NOIRQ_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) >> > >> > >> }; >> > >> > >> >> > >> > >> The existing helper macros EXPORT_*_SIMPLE_DEV_PM_OPS() >> and >> > >> > >> EXPORT_*_RUNTIME_DEV_PM_OPS() have been updated to use >> these >> > >> new >> > >> > >> macros. >> > >> > >> >> > >> > >> Signed-off-by: Paul Cercueil <paul@crapouillou.net> >> > >> > > >> > >> > > Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >> > >> > > >> > >> > > or please let me know if you need me to pick up this one. >> > >> > >> > >> > Could you pick this one up then, and make a branch for >> Jonathan? >> > >> >> > >> Hi Paul, Rafael, >> > >> >> > >> What happened to this in the end? I can't immediately find >> it on >> > >> any of the pm git tree branches. >> > >> >> > >> At this stage in the cycle it would be great if this patch at >> least >> > >> makes the merge window, so we can make use of it next cycle. >> > > >> > > I thought that this would go in along with the other patches in >> the >> > > series. >> > > >> > > I can apply it directly, though, if needed. >> > > >> > > Thanks! >> > >> > I think at this point Jonathan can just take it in his tree with >> his >> > own patchset. Then I'll rebase this patchset on v6.1-rc1. >> >> Sure. >> >> Jonathan, please go ahead and take the patch directly. > > Too late for me to take this for this cycle (I route via Greg KH so > need to have things > in place a little bit before the merge window). If Lee doesn't pick > it up, I'll do an > immutable branch after rc1 is out with just this patch on it, then > anyone who wants > it can pick it up.
Rafael or Lee, can you take it now?
Or is it already too late? :(
-Paul
| |