include/linux/pm_runtime.h | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)
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! >
© 2016 - 2026 Red Hat, Inc.