| Message ID | 20220220181522.541718-3-jic23@kernel.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | IIO: Where dev_pm_ops rework and namespaces meet. | expand |
CC: linux-pm On 2/20/2022 7:15 PM, Jonathan Cameron wrote: > From: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > As more drivers start to use namespaces, we need to have varients of these > useful macros that allow the export to be in a particular namespace. > > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > Cc: Paul Cercueil <paul@crapouillou.net> > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> I'd rather route this through linux-pm unless you have dependent changes. > --- > include/linux/pm.h | 14 +++++++++----- > include/linux/pm_runtime.h | 10 ++++++++-- > 2 files changed, 17 insertions(+), 7 deletions(-) > > diff --git a/include/linux/pm.h b/include/linux/pm.h > index f7d2be686359..112b8125d4be 100644 > --- a/include/linux/pm.h > +++ b/include/linux/pm.h > @@ -368,13 +368,13 @@ const struct dev_pm_ops name = { \ > > #ifdef CONFIG_PM > #define _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, runtime_suspend_fn, \ > - runtime_resume_fn, idle_fn, sec) \ > + runtime_resume_fn, idle_fn, sec, ns) \ > _DEFINE_DEV_PM_OPS(name, suspend_fn, resume_fn, runtime_suspend_fn, \ > runtime_resume_fn, idle_fn); \ > - _EXPORT_SYMBOL(name, sec) > + __EXPORT_SYMBOL(name, sec, ns) > #else > #define _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, runtime_suspend_fn, \ > - runtime_resume_fn, idle_fn, sec) \ > + runtime_resume_fn, idle_fn, sec, ns) \ > static __maybe_unused _DEFINE_DEV_PM_OPS(__static_##name, suspend_fn, \ > resume_fn, runtime_suspend_fn, \ > runtime_resume_fn, idle_fn) > @@ -391,9 +391,13 @@ static __maybe_unused _DEFINE_DEV_PM_OPS(__static_##name, suspend_fn, \ > _DEFINE_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL) > > #define EXPORT_SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \ > - _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL, "") > + _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL, "", "") > #define EXPORT_GPL_SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \ > - _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL, "_gpl") > + _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL, "_gpl", "") > +#define EXPORT_NS_SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn, ns) \ > + _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL, "", #ns) > +#define EXPORT_NS_GPL_SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn, ns) \ > + _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL, "_gpl", #ns) > > /* Deprecated. Use DEFINE_SIMPLE_DEV_PM_OPS() instead. */ > #define SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \ > diff --git a/include/linux/pm_runtime.h b/include/linux/pm_runtime.h > index 9f09601c465a..6a8b9551ecad 100644 > --- a/include/linux/pm_runtime.h > +++ b/include/linux/pm_runtime.h > @@ -41,10 +41,16 @@ > > #define EXPORT_RUNTIME_DEV_PM_OPS(name, suspend_fn, resume_fn, idle_fn) \ > _EXPORT_DEV_PM_OPS(name, pm_runtime_force_suspend, pm_runtime_force_resume, \ > - suspend_fn, resume_fn, idle_fn, "") > + suspend_fn, resume_fn, idle_fn, "", "") > #define EXPORT_GPL_RUNTIME_DEV_PM_OPS(name, suspend_fn, resume_fn, idle_fn) \ > _EXPORT_DEV_PM_OPS(name, pm_runtime_force_suspend, pm_runtime_force_resume, \ > - suspend_fn, resume_fn, idle_fn, "_gpl") > + suspend_fn, resume_fn, idle_fn, "_gpl", "") > +#define EXPORT_NS_RUNTIME_DEV_PM_OPS(name, suspend_fn, resume_fn, idle_fn, ns) \ > + _EXPORT_DEV_PM_OPS(name, pm_runtime_force_suspend, pm_runtime_force_resume, \ > + suspend_fn, resume_fn, idle_fn, "", #ns) > +#define EXPORT_NS_GPL_RUNTIME_DEV_PM_OPS(name, suspend_fn, resume_fn, idle_fn, ns) \ > + _EXPORT_DEV_PM_OPS(name, pm_runtime_force_suspend, pm_runtime_force_resume, \ > + suspend_fn, resume_fn, idle_fn, "_gpl", #ns) > > #ifdef CONFIG_PM > extern struct workqueue_struct *pm_wq;
On Mon, 21 Feb 2022 20:37:57 +0100 "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> wrote: Hi Rafael, > CC: linux-pm Oops. Stupid omission on my part, sorry about that! > > On 2/20/2022 7:15 PM, Jonathan Cameron wrote: > > From: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > > > As more drivers start to use namespaces, we need to have varients of these > > useful macros that allow the export to be in a particular namespace. > > > > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > Cc: Paul Cercueil <paul@crapouillou.net> > > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > I'd rather route this through linux-pm unless you have dependent changes. Ok. The kxsd9 patch (4) is dependent on other changes queued for the merge window in IIO. If we want to do it through linux-pm I'd love it if we can manage to get the ground work in for the coming merge window. So options are: 1) This patch alone via linux-pm and I queue the users up for next cycle Fine by me but always awkward to have infrastructure with no users. 2) First 3 patches via linux-pm so we have a user (scd30) in a low churn driver and I'll queue the rest for 5.19. Fine by me as well. That goes on cleanly on 5.17-rc1 and there is nothing else in my review queue touching that driver. I'm also interested to hear your view on the discussion going on in reply to the cover letter. Specifically Paul suggested we 'only' have the namespaced versions of these macros. Thanks, Jonathan > > > > --- > > include/linux/pm.h | 14 +++++++++----- > > include/linux/pm_runtime.h | 10 ++++++++-- > > 2 files changed, 17 insertions(+), 7 deletions(-) > > > > diff --git a/include/linux/pm.h b/include/linux/pm.h > > index f7d2be686359..112b8125d4be 100644 > > --- a/include/linux/pm.h > > +++ b/include/linux/pm.h > > @@ -368,13 +368,13 @@ const struct dev_pm_ops name = { \ > > > > #ifdef CONFIG_PM > > #define _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, runtime_suspend_fn, \ > > - runtime_resume_fn, idle_fn, sec) \ > > + runtime_resume_fn, idle_fn, sec, ns) \ > > _DEFINE_DEV_PM_OPS(name, suspend_fn, resume_fn, runtime_suspend_fn, \ > > runtime_resume_fn, idle_fn); \ > > - _EXPORT_SYMBOL(name, sec) > > + __EXPORT_SYMBOL(name, sec, ns) > > #else > > #define _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, runtime_suspend_fn, \ > > - runtime_resume_fn, idle_fn, sec) \ > > + runtime_resume_fn, idle_fn, sec, ns) \ > > static __maybe_unused _DEFINE_DEV_PM_OPS(__static_##name, suspend_fn, \ > > resume_fn, runtime_suspend_fn, \ > > runtime_resume_fn, idle_fn) > > @@ -391,9 +391,13 @@ static __maybe_unused _DEFINE_DEV_PM_OPS(__static_##name, suspend_fn, \ > > _DEFINE_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL) > > > > #define EXPORT_SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \ > > - _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL, "") > > + _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL, "", "") > > #define EXPORT_GPL_SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \ > > - _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL, "_gpl") > > + _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL, "_gpl", "") > > +#define EXPORT_NS_SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn, ns) \ > > + _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL, "", #ns) > > +#define EXPORT_NS_GPL_SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn, ns) \ > > + _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL, "_gpl", #ns) > > > > /* Deprecated. Use DEFINE_SIMPLE_DEV_PM_OPS() instead. */ > > #define SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \ > > diff --git a/include/linux/pm_runtime.h b/include/linux/pm_runtime.h > > index 9f09601c465a..6a8b9551ecad 100644 > > --- a/include/linux/pm_runtime.h > > +++ b/include/linux/pm_runtime.h > > @@ -41,10 +41,16 @@ > > > > #define EXPORT_RUNTIME_DEV_PM_OPS(name, suspend_fn, resume_fn, idle_fn) \ > > _EXPORT_DEV_PM_OPS(name, pm_runtime_force_suspend, pm_runtime_force_resume, \ > > - suspend_fn, resume_fn, idle_fn, "") > > + suspend_fn, resume_fn, idle_fn, "", "") > > #define EXPORT_GPL_RUNTIME_DEV_PM_OPS(name, suspend_fn, resume_fn, idle_fn) \ > > _EXPORT_DEV_PM_OPS(name, pm_runtime_force_suspend, pm_runtime_force_resume, \ > > - suspend_fn, resume_fn, idle_fn, "_gpl") > > + suspend_fn, resume_fn, idle_fn, "_gpl", "") > > +#define EXPORT_NS_RUNTIME_DEV_PM_OPS(name, suspend_fn, resume_fn, idle_fn, ns) \ > > + _EXPORT_DEV_PM_OPS(name, pm_runtime_force_suspend, pm_runtime_force_resume, \ > > + suspend_fn, resume_fn, idle_fn, "", #ns) > > +#define EXPORT_NS_GPL_RUNTIME_DEV_PM_OPS(name, suspend_fn, resume_fn, idle_fn, ns) \ > > + _EXPORT_DEV_PM_OPS(name, pm_runtime_force_suspend, pm_runtime_force_resume, \ > > + suspend_fn, resume_fn, idle_fn, "_gpl", #ns) > > > > #ifdef CONFIG_PM > > extern struct workqueue_struct *pm_wq; > >
On Sun, Feb 27, 2022 at 12:39 PM Jonathan Cameron <jic23@kernel.org> wrote: > > On Mon, 21 Feb 2022 20:37:57 +0100 > "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> wrote: > > Hi Rafael, > > CC: linux-pm > > Oops. Stupid omission on my part, sorry about that! > > > > > On 2/20/2022 7:15 PM, Jonathan Cameron wrote: > > > From: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > > > > > As more drivers start to use namespaces, we need to have varients of these > > > useful macros that allow the export to be in a particular namespace. > > > > > > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > > Cc: Paul Cercueil <paul@crapouillou.net> > > > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > I'd rather route this through linux-pm unless you have dependent changes. > > Ok. > > The kxsd9 patch (4) is dependent on other changes queued for > the merge window in IIO. If we want to do it through linux-pm I'd > love it if we can manage to get the ground work in for the coming merge window. > > So options are: > > 1) This patch alone via linux-pm and I queue the users up for next cycle > Fine by me but always awkward to have infrastructure with no users. > 2) First 3 patches via linux-pm so we have a user (scd30) in a low churn > driver and I'll queue the rest for 5.19. Fine by me as well. > That goes on cleanly on 5.17-rc1 and there is nothing else in my review > queue touching that driver. That would work for me. > I'm also interested to hear your view on the discussion going on in reply > to the cover letter. Specifically Paul suggested we 'only' have the > namespaced versions of these macros. Well, I'm a bit afraid that providing the namespaced versions only would slow down the adoption.
On Mon, 28 Feb 2022 21:13:25 +0100 "Rafael J. Wysocki" <rafael@kernel.org> wrote: > On Sun, Feb 27, 2022 at 12:39 PM Jonathan Cameron <jic23@kernel.org> wrote: > > > > On Mon, 21 Feb 2022 20:37:57 +0100 > > "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> wrote: > > > > Hi Rafael, > > > CC: linux-pm > > > > Oops. Stupid omission on my part, sorry about that! > > > > > > > > On 2/20/2022 7:15 PM, Jonathan Cameron wrote: > > > > From: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > > > > > > > As more drivers start to use namespaces, we need to have varients of these > > > > useful macros that allow the export to be in a particular namespace. > > > > > > > > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > > > Cc: Paul Cercueil <paul@crapouillou.net> > > > > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > > > I'd rather route this through linux-pm unless you have dependent changes. > > > > Ok. > > > > The kxsd9 patch (4) is dependent on other changes queued for > > the merge window in IIO. If we want to do it through linux-pm I'd > > love it if we can manage to get the ground work in for the coming merge window. > > > > So options are: > > > > 1) This patch alone via linux-pm and I queue the users up for next cycle > > Fine by me but always awkward to have infrastructure with no users. > > 2) First 3 patches via linux-pm so we have a user (scd30) in a low churn > > driver and I'll queue the rest for 5.19. Fine by me as well. > > That goes on cleanly on 5.17-rc1 and there is nothing else in my review > > queue touching that driver. > > That would work for me. Great. Let's do that then. Are you fine picking them from this thread, or would you like me to resend with just those 3 patches as a fresh series? > > > I'm also interested to hear your view on the discussion going on in reply > > to the cover letter. Specifically Paul suggested we 'only' have the > > namespaced versions of these macros. > > Well, I'm a bit afraid that providing the namespaced versions only > would slow down the adoption. Agreed, that's a concern and as Paul was happy with the route of adding NS and perhaps looking eventually at dropping the non NS variant I think we can move forward with this patch. Thanks, Jonathan
On Tue, 1 Mar 2022 11:31:45 +0000 Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote: > On Mon, 28 Feb 2022 21:13:25 +0100 > "Rafael J. Wysocki" <rafael@kernel.org> wrote: > > > On Sun, Feb 27, 2022 at 12:39 PM Jonathan Cameron <jic23@kernel.org> wrote: > > > > > > On Mon, 21 Feb 2022 20:37:57 +0100 > > > "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> wrote: > > > > > > Hi Rafael, > > > > CC: linux-pm > > > > > > Oops. Stupid omission on my part, sorry about that! > > > > > > > > > > > On 2/20/2022 7:15 PM, Jonathan Cameron wrote: > > > > > From: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > > > > > > > > > As more drivers start to use namespaces, we need to have varients of these > > > > > useful macros that allow the export to be in a particular namespace. > > > > > > > > > > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > > > > Cc: Paul Cercueil <paul@crapouillou.net> > > > > > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > > > > > I'd rather route this through linux-pm unless you have dependent changes. > > > > > > Ok. > > > > > > The kxsd9 patch (4) is dependent on other changes queued for > > > the merge window in IIO. If we want to do it through linux-pm I'd > > > love it if we can manage to get the ground work in for the coming merge window. > > > > > > So options are: > > > > > > 1) This patch alone via linux-pm and I queue the users up for next cycle > > > Fine by me but always awkward to have infrastructure with no users. > > > 2) First 3 patches via linux-pm so we have a user (scd30) in a low churn > > > driver and I'll queue the rest for 5.19. Fine by me as well. > > > That goes on cleanly on 5.17-rc1 and there is nothing else in my review > > > queue touching that driver. > > > > That would work for me. > > Great. Let's do that then. Are you fine picking them from this thread, or > would you like me to resend with just those 3 patches as a fresh series? Hi Rafael, I've not heard back from you, so have been assuming you'd pick those first 3 patches up from this series. Is that a correct assumption? Thanks, Jonathan > > > > > > I'm also interested to hear your view on the discussion going on in reply > > > to the cover letter. Specifically Paul suggested we 'only' have the > > > namespaced versions of these macros. > > > > Well, I'm a bit afraid that providing the namespaced versions only > > would slow down the adoption. > > Agreed, that's a concern and as Paul was happy with the route of > adding NS and perhaps looking eventually at dropping the non NS variant > I think we can move forward with this patch. > > Thanks, > > Jonathan > >
Hi Jonathan, On Wed, Mar 30, 2022 at 2:30 PM Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote: > > On Tue, 1 Mar 2022 11:31:45 +0000 > Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote: > > > On Mon, 28 Feb 2022 21:13:25 +0100 > > "Rafael J. Wysocki" <rafael@kernel.org> wrote: > > > > > On Sun, Feb 27, 2022 at 12:39 PM Jonathan Cameron <jic23@kernel.org> wrote: > > > > > > > > On Mon, 21 Feb 2022 20:37:57 +0100 > > > > "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> wrote: > > > > > > > > Hi Rafael, > > > > > CC: linux-pm > > > > > > > > Oops. Stupid omission on my part, sorry about that! > > > > > > > > > > > > > > On 2/20/2022 7:15 PM, Jonathan Cameron wrote: > > > > > > From: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > > > > > > > > > > > As more drivers start to use namespaces, we need to have varients of these > > > > > > useful macros that allow the export to be in a particular namespace. > > > > > > > > > > > > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > > > > > Cc: Paul Cercueil <paul@crapouillou.net> > > > > > > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > > > > > > > I'd rather route this through linux-pm unless you have dependent changes. > > > > > > > > Ok. > > > > > > > > The kxsd9 patch (4) is dependent on other changes queued for > > > > the merge window in IIO. If we want to do it through linux-pm I'd > > > > love it if we can manage to get the ground work in for the coming merge window. > > > > > > > > So options are: > > > > > > > > 1) This patch alone via linux-pm and I queue the users up for next cycle > > > > Fine by me but always awkward to have infrastructure with no users. > > > > 2) First 3 patches via linux-pm so we have a user (scd30) in a low churn > > > > driver and I'll queue the rest for 5.19. Fine by me as well. > > > > That goes on cleanly on 5.17-rc1 and there is nothing else in my review > > > > queue touching that driver. > > > > > > That would work for me. > > > > Great. Let's do that then. Are you fine picking them from this thread, or > > would you like me to resend with just those 3 patches as a fresh series? > Hi Rafael, > > I've not heard back from you, so have been assuming you'd pick those first > 3 patches up from this series. Is that a correct assumption? This was my intention, but then I lost track of them and now I can't find them in the linux-pm Patchwork. Sorry about this. Can you please resend just the 3 patches? Thanks!
On Thu, 31 Mar 2022 19:21:14 +0200 "Rafael J. Wysocki" <rafael@kernel.org> wrote: > Hi Jonathan, > > On Wed, Mar 30, 2022 at 2:30 PM Jonathan Cameron > <Jonathan.Cameron@huawei.com> wrote: > > > > On Tue, 1 Mar 2022 11:31:45 +0000 > > Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote: > > > > > On Mon, 28 Feb 2022 21:13:25 +0100 > > > "Rafael J. Wysocki" <rafael@kernel.org> wrote: > > > > > > > On Sun, Feb 27, 2022 at 12:39 PM Jonathan Cameron <jic23@kernel.org> wrote: > > > > > > > > > > On Mon, 21 Feb 2022 20:37:57 +0100 > > > > > "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> wrote: > > > > > > > > > > Hi Rafael, > > > > > > CC: linux-pm > > > > > > > > > > Oops. Stupid omission on my part, sorry about that! > > > > > > > > > > > > > > > > > On 2/20/2022 7:15 PM, Jonathan Cameron wrote: > > > > > > > From: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > > > > > > > > > > > > > As more drivers start to use namespaces, we need to have varients of these > > > > > > > useful macros that allow the export to be in a particular namespace. > > > > > > > > > > > > > > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > > > > > > Cc: Paul Cercueil <paul@crapouillou.net> > > > > > > > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > > > > > > > > > I'd rather route this through linux-pm unless you have dependent changes. > > > > > > > > > > Ok. > > > > > > > > > > The kxsd9 patch (4) is dependent on other changes queued for > > > > > the merge window in IIO. If we want to do it through linux-pm I'd > > > > > love it if we can manage to get the ground work in for the coming merge window. > > > > > > > > > > So options are: > > > > > > > > > > 1) This patch alone via linux-pm and I queue the users up for next cycle > > > > > Fine by me but always awkward to have infrastructure with no users. > > > > > 2) First 3 patches via linux-pm so we have a user (scd30) in a low churn > > > > > driver and I'll queue the rest for 5.19. Fine by me as well. > > > > > That goes on cleanly on 5.17-rc1 and there is nothing else in my review > > > > > queue touching that driver. > > > > > > > > That would work for me. > > > > > > Great. Let's do that then. Are you fine picking them from this thread, or > > > would you like me to resend with just those 3 patches as a fresh series? > > Hi Rafael, > > > > I've not heard back from you, so have been assuming you'd pick those first > > 3 patches up from this series. Is that a correct assumption? > > This was my intention, but then I lost track of them and now I can't > find them in the linux-pm Patchwork. Sorry about this. My fault, I think I forgot to cc linux-pm on the initial send and you added it in your reply. > > Can you please resend just the 3 patches? On their way. > > Thanks!
diff --git a/include/linux/pm.h b/include/linux/pm.h index f7d2be686359..112b8125d4be 100644 --- a/include/linux/pm.h +++ b/include/linux/pm.h @@ -368,13 +368,13 @@ const struct dev_pm_ops name = { \ #ifdef CONFIG_PM #define _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, runtime_suspend_fn, \ - runtime_resume_fn, idle_fn, sec) \ + runtime_resume_fn, idle_fn, sec, ns) \ _DEFINE_DEV_PM_OPS(name, suspend_fn, resume_fn, runtime_suspend_fn, \ runtime_resume_fn, idle_fn); \ - _EXPORT_SYMBOL(name, sec) + __EXPORT_SYMBOL(name, sec, ns) #else #define _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, runtime_suspend_fn, \ - runtime_resume_fn, idle_fn, sec) \ + runtime_resume_fn, idle_fn, sec, ns) \ static __maybe_unused _DEFINE_DEV_PM_OPS(__static_##name, suspend_fn, \ resume_fn, runtime_suspend_fn, \ runtime_resume_fn, idle_fn) @@ -391,9 +391,13 @@ static __maybe_unused _DEFINE_DEV_PM_OPS(__static_##name, suspend_fn, \ _DEFINE_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL) #define EXPORT_SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \ - _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL, "") + _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL, "", "") #define EXPORT_GPL_SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \ - _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL, "_gpl") + _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL, "_gpl", "") +#define EXPORT_NS_SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn, ns) \ + _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL, "", #ns) +#define EXPORT_NS_GPL_SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn, ns) \ + _EXPORT_DEV_PM_OPS(name, suspend_fn, resume_fn, NULL, NULL, NULL, "_gpl", #ns) /* Deprecated. Use DEFINE_SIMPLE_DEV_PM_OPS() instead. */ #define SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \ diff --git a/include/linux/pm_runtime.h b/include/linux/pm_runtime.h index 9f09601c465a..6a8b9551ecad 100644 --- a/include/linux/pm_runtime.h +++ b/include/linux/pm_runtime.h @@ -41,10 +41,16 @@ #define EXPORT_RUNTIME_DEV_PM_OPS(name, suspend_fn, resume_fn, idle_fn) \ _EXPORT_DEV_PM_OPS(name, pm_runtime_force_suspend, pm_runtime_force_resume, \ - suspend_fn, resume_fn, idle_fn, "") + suspend_fn, resume_fn, idle_fn, "", "") #define EXPORT_GPL_RUNTIME_DEV_PM_OPS(name, suspend_fn, resume_fn, idle_fn) \ _EXPORT_DEV_PM_OPS(name, pm_runtime_force_suspend, pm_runtime_force_resume, \ - suspend_fn, resume_fn, idle_fn, "_gpl") + suspend_fn, resume_fn, idle_fn, "_gpl", "") +#define EXPORT_NS_RUNTIME_DEV_PM_OPS(name, suspend_fn, resume_fn, idle_fn, ns) \ + _EXPORT_DEV_PM_OPS(name, pm_runtime_force_suspend, pm_runtime_force_resume, \ + suspend_fn, resume_fn, idle_fn, "", #ns) +#define EXPORT_NS_GPL_RUNTIME_DEV_PM_OPS(name, suspend_fn, resume_fn, idle_fn, ns) \ + _EXPORT_DEV_PM_OPS(name, pm_runtime_force_suspend, pm_runtime_force_resume, \ + suspend_fn, resume_fn, idle_fn, "_gpl", #ns) #ifdef CONFIG_PM extern struct workqueue_struct *pm_wq;