* Re: [PATCH 2/8] PM: core: Add NS varients of EXPORT[_GPL]_SIMPLE_DEV_PM_OPS and runtime pm equiv [not found] ` <20220220181522.541718-3-jic23@kernel.org> @ 2022-02-21 19:37 ` Rafael J. Wysocki 2022-02-27 11:46 ` Jonathan Cameron 0 siblings, 1 reply; 7+ messages in thread From: Rafael J. Wysocki @ 2022-02-21 19:37 UTC (permalink / raw) To: Jonathan Cameron, linux-iio Cc: Paul Cercueil, Rafael J . Wysocki, Lorenzo Bianconi, Tomasz Duszynski, Jonathan Cameron, Linux PM 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; ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2/8] PM: core: Add NS varients of EXPORT[_GPL]_SIMPLE_DEV_PM_OPS and runtime pm equiv 2022-02-21 19:37 ` [PATCH 2/8] PM: core: Add NS varients of EXPORT[_GPL]_SIMPLE_DEV_PM_OPS and runtime pm equiv Rafael J. Wysocki @ 2022-02-27 11:46 ` Jonathan Cameron 2022-02-28 20:13 ` Rafael J. Wysocki 0 siblings, 1 reply; 7+ messages in thread From: Jonathan Cameron @ 2022-02-27 11:46 UTC (permalink / raw) To: Rafael J. Wysocki Cc: linux-iio, Paul Cercueil, Rafael J . Wysocki, Lorenzo Bianconi, Tomasz Duszynski, Jonathan Cameron, Linux PM 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; > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2/8] PM: core: Add NS varients of EXPORT[_GPL]_SIMPLE_DEV_PM_OPS and runtime pm equiv 2022-02-27 11:46 ` Jonathan Cameron @ 2022-02-28 20:13 ` Rafael J. Wysocki 2022-03-01 11:31 ` Jonathan Cameron 0 siblings, 1 reply; 7+ messages in thread From: Rafael J. Wysocki @ 2022-02-28 20:13 UTC (permalink / raw) To: Jonathan Cameron Cc: Rafael J. Wysocki, linux-iio, Paul Cercueil, Rafael J . Wysocki, Lorenzo Bianconi, Tomasz Duszynski, Jonathan Cameron, Linux PM 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2/8] PM: core: Add NS varients of EXPORT[_GPL]_SIMPLE_DEV_PM_OPS and runtime pm equiv 2022-02-28 20:13 ` Rafael J. Wysocki @ 2022-03-01 11:31 ` Jonathan Cameron 2022-03-30 12:30 ` Jonathan Cameron 0 siblings, 1 reply; 7+ messages in thread From: Jonathan Cameron @ 2022-03-01 11:31 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Jonathan Cameron, Rafael J. Wysocki, linux-iio, Paul Cercueil, Lorenzo Bianconi, Tomasz Duszynski, Linux PM 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2/8] PM: core: Add NS varients of EXPORT[_GPL]_SIMPLE_DEV_PM_OPS and runtime pm equiv 2022-03-01 11:31 ` Jonathan Cameron @ 2022-03-30 12:30 ` Jonathan Cameron 2022-03-31 17:21 ` Rafael J. Wysocki 0 siblings, 1 reply; 7+ messages in thread From: Jonathan Cameron @ 2022-03-30 12:30 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Jonathan Cameron, Rafael J. Wysocki, linux-iio, Paul Cercueil, Lorenzo Bianconi, Tomasz Duszynski, Linux PM 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 > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2/8] PM: core: Add NS varients of EXPORT[_GPL]_SIMPLE_DEV_PM_OPS and runtime pm equiv 2022-03-30 12:30 ` Jonathan Cameron @ 2022-03-31 17:21 ` Rafael J. Wysocki 2022-04-01 14:06 ` Jonathan Cameron 0 siblings, 1 reply; 7+ messages in thread From: Rafael J. Wysocki @ 2022-03-31 17:21 UTC (permalink / raw) To: Jonathan Cameron Cc: Rafael J. Wysocki, Jonathan Cameron, Rafael J. Wysocki, linux-iio, Paul Cercueil, Lorenzo Bianconi, Tomasz Duszynski, Linux PM 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! ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2/8] PM: core: Add NS varients of EXPORT[_GPL]_SIMPLE_DEV_PM_OPS and runtime pm equiv 2022-03-31 17:21 ` Rafael J. Wysocki @ 2022-04-01 14:06 ` Jonathan Cameron 0 siblings, 0 replies; 7+ messages in thread From: Jonathan Cameron @ 2022-04-01 14:06 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Jonathan Cameron, Rafael J. Wysocki, linux-iio, Paul Cercueil, Lorenzo Bianconi, Tomasz Duszynski, Linux PM 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! ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-04-01 14:06 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20220220181522.541718-1-jic23@kernel.org>
[not found] ` <20220220181522.541718-3-jic23@kernel.org>
2022-02-21 19:37 ` [PATCH 2/8] PM: core: Add NS varients of EXPORT[_GPL]_SIMPLE_DEV_PM_OPS and runtime pm equiv Rafael J. Wysocki
2022-02-27 11:46 ` Jonathan Cameron
2022-02-28 20:13 ` Rafael J. Wysocki
2022-03-01 11:31 ` Jonathan Cameron
2022-03-30 12:30 ` Jonathan Cameron
2022-03-31 17:21 ` Rafael J. Wysocki
2022-04-01 14:06 ` Jonathan Cameron
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).