Re: [PATCH v1 0/3] PM: runtime: Wrapper macros for usage counter guards

[Dhruva Gole <d-gole@ti.com>]

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