Hi All, The runtime PM usage counter guards introduced recently: https://lore.kernel.org/linux-pm/6196611.lOV4Wx5bFT@rafael.j.wysocki/ and then fixed: https://lore.kernel.org/linux-pm/5943878.DvuYhMxLoT@rafael.j.wysocki/ should generally work, but using them feels sort of arcane and cryptic even though the underlying concept is relatively straightforward. For this reason, runtime PM wrapper macros around ACQUIRE() and ACQUIRE_ERR() involving the new guards are introduced in this series (patch [1/3]) and then used in the code already using the guards (patches [2/3] and [3/3]) to make it look more straightforward. Thanks!
On Nov 07, 2025 at 19:35:09 +0100, Rafael J. Wysocki wrote: > Hi All, > > The runtime PM usage counter guards introduced recently: > > https://lore.kernel.org/linux-pm/6196611.lOV4Wx5bFT@rafael.j.wysocki/ > > and then fixed: > > https://lore.kernel.org/linux-pm/5943878.DvuYhMxLoT@rafael.j.wysocki/ > > should generally work, but using them feels sort of arcane and cryptic > even though the underlying concept is relatively straightforward. > > For this reason, runtime PM wrapper macros around ACQUIRE() and > ACQUIRE_ERR() involving the new guards are introduced in this series > (patch [1/3]) and then used in the code already using the guards (patches > [2/3] and [3/3]) to make it look more straightforward. The patches look okay to me, Reviewed-by: Dhruva Gole <d-gole@ti.com> -- Best regards, Dhruva Gole Texas Instruments Incorporated
On Wednesday, November 12, 2025 7:39:41 AM CET Dhruva Gole wrote:
> On Nov 07, 2025 at 19:35:09 +0100, Rafael J. Wysocki wrote:
> > Hi All,
> >
> > The runtime PM usage counter guards introduced recently:
> >
> > https://lore.kernel.org/linux-pm/6196611.lOV4Wx5bFT@rafael.j.wysocki/
> >
> > and then fixed:
> >
> > https://lore.kernel.org/linux-pm/5943878.DvuYhMxLoT@rafael.j.wysocki/
> >
> > should generally work, but using them feels sort of arcane and cryptic
> > even though the underlying concept is relatively straightforward.
> >
> > For this reason, runtime PM wrapper macros around ACQUIRE() and
> > ACQUIRE_ERR() involving the new guards are introduced in this series
> > (patch [1/3]) and then used in the code already using the guards (patches
> > [2/3] and [3/3]) to make it look more straightforward.
>
> The patches look okay to me,
> Reviewed-by: Dhruva Gole <d-gole@ti.com>
Thank you and Jonathan for the tags, but since Frank is not convinced, let me
bounce one more idea off all of you.
Namely, I think that Frank has a point when he wonders if PM_RUNTIME_ACQUIRE_ERR
hides too much information and I agree with Jonathan that may be misunderstood,
so what about defining the wrapper macros so they don't hide the guard variable
name, like in the patch below?
---
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Subject: [PATCH v2] PM: runtime: Wrapper macros for ACQUIRE()/ACQUIRE_ERR()
Add several wrapper macros for ACQUIRE()/ACQUIRE_ERR() and runtime PM
usage counter guards introduced recently: pm_runtime_active_try,
pm_runtime_active_auto_try, pm_runtime_active_try_enabled, and
pm_runtime_active_auto_try_enabled.
The new macros are simpler and should be more straightforward to use.
For example, they can be used for rewriting a piece of code like below:
ACQUIRE(pm_runtime_active_try, pm)(dev);
if ((ret = ACQUIRE_ERR(pm_runtime_active_try, &pm)))
return ret;
in the following way:
PM_RUNTIME_ACQUIRE(dev, pm);
if ((ret = PM_RUNTIME_ACQUIRE_ERR(pm)))
return ret;
If the original code does not care about the specific error code
returned when attempting to resume the device:
ACQUIRE(pm_runtime_active_try, pm)(dev);
if (ACQUIRE_ERR(pm_runtime_active_try, &pm))
return -ENXIO;
it may be changed like this:
PM_RUNTIME_ACQUIRE(dev, pm);
if (PM_RUNTIME_ACQUIRE_ERR(pm))
return -ENXIO;
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
include/linux/pm_runtime.h | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
--- a/include/linux/pm_runtime.h
+++ b/include/linux/pm_runtime.h
@@ -637,6 +637,31 @@ DEFINE_GUARD_COND(pm_runtime_active_auto
DEFINE_GUARD_COND(pm_runtime_active_auto, _try_enabled,
pm_runtime_resume_and_get(_T), _RET == 0)
+/* ACQUIRE() wrapper macros for the guards defined above. */
+
+#define PM_RUNTIME_ACQUIRE(dev, var_name) \
+ ACQUIRE(pm_runtime_active_try, var_name)(dev)
+
+#define PM_RUNTIME_ACQUIRE_AUTOSUSPEND(dev, var_name) \
+ ACQUIRE(pm_runtime_active_auto_try, var_name)(dev)
+
+#define PM_RUNTIME_ACQUIRE_IF_ENABLED(dev, var_name) \
+ ACQUIRE(pm_runtime_active_try_enabled, var_name)(dev)
+
+#define PM_RUNTIME_ACQUIRE_IF_ENABLED_AUTOSUSPEND(dev, var_name) \
+ ACQUIRE(pm_runtime_active_auto_try_enabled, var_name)(dev)
+
+/*
+ * ACQUIRE_ERR() wrapper macro for guard pm_runtime_active.
+ *
+ * Always check PM_RUNTIME_ACQUIRE_ERR() after using one of the
+ * PM_RUNTIME_ACQUIRE*() macros defined above (yes, it can be used
+ * with any of them) and avoid accessing the given device if it is
+ * nonzero.
+ */
+#define PM_RUNTIME_ACQUIRE_ERR(var_name) \
+ ACQUIRE_ERR(pm_runtime_active, &var_name)
+
/**
* pm_runtime_put_sync - Drop device usage counter and run "idle check" if 0.
* @dev: Target device.Rafael J. Wysocki wrote:
> On Wednesday, November 12, 2025 7:39:41 AM CET Dhruva Gole wrote:
> > On Nov 07, 2025 at 19:35:09 +0100, Rafael J. Wysocki wrote:
> > > Hi All,
> > >
> > > The runtime PM usage counter guards introduced recently:
> > >
> > > https://lore.kernel.org/linux-pm/6196611.lOV4Wx5bFT@rafael.j.wysocki/
> > >
> > > and then fixed:
> > >
> > > https://lore.kernel.org/linux-pm/5943878.DvuYhMxLoT@rafael.j.wysocki/
> > >
> > > should generally work, but using them feels sort of arcane and cryptic
> > > even though the underlying concept is relatively straightforward.
> > >
> > > For this reason, runtime PM wrapper macros around ACQUIRE() and
> > > ACQUIRE_ERR() involving the new guards are introduced in this series
> > > (patch [1/3]) and then used in the code already using the guards (patches
> > > [2/3] and [3/3]) to make it look more straightforward.
> >
> > The patches look okay to me,
> > Reviewed-by: Dhruva Gole <d-gole@ti.com>
>
> Thank you and Jonathan for the tags, but since Frank is not convinced, let me
> bounce one more idea off all of you.
>
> Namely, I think that Frank has a point when he wonders if PM_RUNTIME_ACQUIRE_ERR
> hides too much information and I agree with Jonathan that may be misunderstood,
> so what about defining the wrapper macros so they don't hide the guard variable
> name, like in the patch below?
I had been reluctant about offering an enthusiastic tag on this series
given that information hiding, but with this change:
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
However, I prefer that the scope variable declaration vs usage
(reference) cases should maintain visual separation with an operator,
i.e.:
PM_RUNTIME_ACQUIRE(dev, pm);
if (PM_RUNTIME_ACQUIRE_ERR(&pm))
return -ENXIO;
Otherwise we have a case of different flavors of *_ACQUIRE_ERR
implementing various styles. I initially looked at hiding the '&':
http://lore.kernel.org/681ea7d5ea04b_2a2bb100cf@dwillia2-mobl4.notmuch
...but it grew on me precisely because it provides a clue about how this
magic operates.
On Nov 12, 2025 at 13:27:17 -0800, dan.j.williams@intel.com wrote: > Rafael J. Wysocki wrote: > > On Wednesday, November 12, 2025 7:39:41 AM CET Dhruva Gole wrote: > > > On Nov 07, 2025 at 19:35:09 +0100, Rafael J. Wysocki wrote: > > > > Hi All, > > > > > > > > The runtime PM usage counter guards introduced recently: > > > > > > > > https://lore.kernel.org/linux-pm/6196611.lOV4Wx5bFT@rafael.j.wysocki/ > > > > > > > > and then fixed: > > > > > > > > https://lore.kernel.org/linux-pm/5943878.DvuYhMxLoT@rafael.j.wysocki/ > > > > > > > > should generally work, but using them feels sort of arcane and cryptic > > > > even though the underlying concept is relatively straightforward. > > > > > > > > For this reason, runtime PM wrapper macros around ACQUIRE() and > > > > ACQUIRE_ERR() involving the new guards are introduced in this series > > > > (patch [1/3]) and then used in the code already using the guards (patches > > > > [2/3] and [3/3]) to make it look more straightforward. > > > > > > The patches look okay to me, > > > Reviewed-by: Dhruva Gole <d-gole@ti.com> > > > > Thank you and Jonathan for the tags, but since Frank is not convinced, let me > > bounce one more idea off all of you. > > > > Namely, I think that Frank has a point when he wonders if PM_RUNTIME_ACQUIRE_ERR > > hides too much information and I agree with Jonathan that may be misunderstood, > > so what about defining the wrapper macros so they don't hide the guard variable > > name, like in the patch below? > > I had been reluctant about offering an enthusiastic tag on this series > given that information hiding, but with this change: > > Reviewed-by: Dan Williams <dan.j.williams@intel.com> > > However, I prefer that the scope variable declaration vs usage > (reference) cases should maintain visual separation with an operator, > i.e.: > > PM_RUNTIME_ACQUIRE(dev, pm); > if (PM_RUNTIME_ACQUIRE_ERR(&pm)) > return -ENXIO; > > Otherwise we have a case of different flavors of *_ACQUIRE_ERR > implementing various styles. I initially looked at hiding the '&': > > http://lore.kernel.org/681ea7d5ea04b_2a2bb100cf@dwillia2-mobl4.notmuch > > ...but it grew on me precisely because it provides a clue about how this > magic operates. Yeah you're right, I agree. Having users explicitly pass on the '&' provides much more clarity on what's going on than hiding it internally. -- Best regards, Dhruva Gole Texas Instruments Incorporated
On Wed, Nov 12, 2025 at 10:27 PM <dan.j.williams@intel.com> wrote: > > Rafael J. Wysocki wrote: > > On Wednesday, November 12, 2025 7:39:41 AM CET Dhruva Gole wrote: > > > On Nov 07, 2025 at 19:35:09 +0100, Rafael J. Wysocki wrote: > > > > Hi All, > > > > > > > > The runtime PM usage counter guards introduced recently: > > > > > > > > https://lore.kernel.org/linux-pm/6196611.lOV4Wx5bFT@rafael.j.wysocki/ > > > > > > > > and then fixed: > > > > > > > > https://lore.kernel.org/linux-pm/5943878.DvuYhMxLoT@rafael.j.wysocki/ > > > > > > > > should generally work, but using them feels sort of arcane and cryptic > > > > even though the underlying concept is relatively straightforward. > > > > > > > > For this reason, runtime PM wrapper macros around ACQUIRE() and > > > > ACQUIRE_ERR() involving the new guards are introduced in this series > > > > (patch [1/3]) and then used in the code already using the guards (patches > > > > [2/3] and [3/3]) to make it look more straightforward. > > > > > > The patches look okay to me, > > > Reviewed-by: Dhruva Gole <d-gole@ti.com> > > > > Thank you and Jonathan for the tags, but since Frank is not convinced, let me > > bounce one more idea off all of you. > > > > Namely, I think that Frank has a point when he wonders if PM_RUNTIME_ACQUIRE_ERR > > hides too much information and I agree with Jonathan that may be misunderstood, > > so what about defining the wrapper macros so they don't hide the guard variable > > name, like in the patch below? > > I had been reluctant about offering an enthusiastic tag on this series > given that information hiding, but with this change: > > Reviewed-by: Dan Williams <dan.j.williams@intel.com> Thanks! > However, I prefer that the scope variable declaration vs usage > (reference) cases should maintain visual separation with an operator, > i.e.: > > PM_RUNTIME_ACQUIRE(dev, pm); > if (PM_RUNTIME_ACQUIRE_ERR(&pm)) > return -ENXIO; > > Otherwise we have a case of different flavors of *_ACQUIRE_ERR > implementing various styles. I initially looked at hiding the '&': > > http://lore.kernel.org/681ea7d5ea04b_2a2bb100cf@dwillia2-mobl4.notmuch > > ...but it grew on me precisely because it provides a clue about how this > magic operates. Fair enough. I'll resend the series with this change then. Thank you!
On Wed, 12 Nov 2025 22:38:14 +0100 "Rafael J. Wysocki" <rafael@kernel.org> wrote: > On Wed, Nov 12, 2025 at 10:27 PM <dan.j.williams@intel.com> wrote: > > > > Rafael J. Wysocki wrote: > > > On Wednesday, November 12, 2025 7:39:41 AM CET Dhruva Gole wrote: > > > > On Nov 07, 2025 at 19:35:09 +0100, Rafael J. Wysocki wrote: > > > > > Hi All, > > > > > > > > > > The runtime PM usage counter guards introduced recently: > > > > > > > > > > https://lore.kernel.org/linux-pm/6196611.lOV4Wx5bFT@rafael.j.wysocki/ > > > > > > > > > > and then fixed: > > > > > > > > > > https://lore.kernel.org/linux-pm/5943878.DvuYhMxLoT@rafael.j.wysocki/ > > > > > > > > > > should generally work, but using them feels sort of arcane and cryptic > > > > > even though the underlying concept is relatively straightforward. > > > > > > > > > > For this reason, runtime PM wrapper macros around ACQUIRE() and > > > > > ACQUIRE_ERR() involving the new guards are introduced in this series > > > > > (patch [1/3]) and then used in the code already using the guards (patches > > > > > [2/3] and [3/3]) to make it look more straightforward. > > > > > > > > The patches look okay to me, > > > > Reviewed-by: Dhruva Gole <d-gole@ti.com> > > > > > > Thank you and Jonathan for the tags, but since Frank is not convinced, let me > > > bounce one more idea off all of you. > > > > > > Namely, I think that Frank has a point when he wonders if PM_RUNTIME_ACQUIRE_ERR > > > hides too much information and I agree with Jonathan that may be misunderstood, > > > so what about defining the wrapper macros so they don't hide the guard variable > > > name, like in the patch below? > > > > I had been reluctant about offering an enthusiastic tag on this series > > given that information hiding, but with this change: > > > > Reviewed-by: Dan Williams <dan.j.williams@intel.com> > > Thanks! > > > However, I prefer that the scope variable declaration vs usage > > (reference) cases should maintain visual separation with an operator, > > i.e.: > > > > PM_RUNTIME_ACQUIRE(dev, pm); > > if (PM_RUNTIME_ACQUIRE_ERR(&pm)) > > return -ENXIO; > > > > Otherwise we have a case of different flavors of *_ACQUIRE_ERR > > implementing various styles. I initially looked at hiding the '&': > > > > http://lore.kernel.org/681ea7d5ea04b_2a2bb100cf@dwillia2-mobl4.notmuch > > > > ...but it grew on me precisely because it provides a clue about how this > > magic operates. > > Fair enough. > > I'll resend the series with this change then. This new option is much nicer and not too verbose. > > Thank you! >
On Fri, 07 Nov 2025 19:35:09 +0100 "Rafael J. Wysocki" <rafael@kernel.org> wrote: > Hi All, > > The runtime PM usage counter guards introduced recently: > > https://lore.kernel.org/linux-pm/6196611.lOV4Wx5bFT@rafael.j.wysocki/ > > and then fixed: > > https://lore.kernel.org/linux-pm/5943878.DvuYhMxLoT@rafael.j.wysocki/ > > should generally work, but using them feels sort of arcane and cryptic > even though the underlying concept is relatively straightforward. > > For this reason, runtime PM wrapper macros around ACQUIRE() and > ACQUIRE_ERR() involving the new guards are introduced in this series > (patch [1/3]) and then used in the code already using the guards (patches > [2/3] and [3/3]) to make it look more straightforward. > > Thanks! It's an interesting trade off between completely hiding the magic variables and verbosity. The PM_RUNTIME_ACQUIRE_ERR smells like something we'd expect to be using global state (given no parameters), but it is of course just local with a magic name. Will take a little getting used to but then so does all this cleanup.h magic. So on balance I think this is a good change. Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
© 2016 - 2025 Red Hat, Inc.