* 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).