Re: PM runtime auto-cleanup macros

[Takashi Iwai <tiwai@suse.de>]

On Wed, 10 Sep 2025 16:00:17 +0200,
Takashi Iwai wrote:
> 
> Hi,
> 
> while I worked on the code cleanups in the drivers with the recent
> auto-cleanup macros, I noticed that pm_runtime_get*() and _put*() can
> be also managed with the auto-cleanup gracefully, too.  Actually we
> already defined the __free(pm_runtime_put) in commit bfa4477751e9, and
> there is a (single) user of it in pci-sysfs.c.
> 
> Now I wanted to extend it to pm_runtime_put_autosuspend() as:
> 
> DEFINE_FREE(pm_runtime_put_autosuspend, struct device *,
>            if (_T) pm_runtime_put_autosuspend(_T))
> 
> Then one can use it like
> 
> 	ret = pm_runtime_resume_and_get(dev);
> 	if (ret < 0)
> 		return ret;
> 	struct device *pmdev __free(pm_runtime_put_autosuspend) = dev;
> 
> that is similar as done in pci-sysfs.c.  So far, so good.
> 
> But, I find putting the line like above at each place a bit ugly.
> So I'm wondering whether it'd be better to introduce some helper
> macros, e.g.
> 
> #define pm_runtime_auto_clean(dev, var) \
> 	struct device *var __free(pm_runtime_put) = (dev)

It can be even simpler by assigning a temporary variable such as:

#define pm_runtime_auto_clean(dev) \
	struct device *__pm_runtime_var ## __LINE__ __free(pm_runtime_put) = (dev)


Takashi

> 
> #define pm_runtime_auto_clean_autosuspend(dev, var) \
> 	struct device *var __free(pm_runtime_put_autosuspend) = (dev)
> 
> and the code will be like:
> 
> 	pm_runtime_get_sync(dev);
> 	pm_runtime_auto_clean(dev, pmdev);
> 
> or
> 	ret = pm_runtime_resume_and_get(dev);
> 	if (ret < 0)
> 		return ret;
> 	pm_runtime_auto_clean_autosuspend(dev, pmdev);
> 
> Alternatively, we may define a class, e.g.
> 
> 	CLASS(pm_runtime_resume_and_get, pmdev);
> 	if (pmdev.ret < 0)
> 		return pmdev.ret;
> 
> but it'll be a bit more code to define the full class, and the get*()
> and put*() combination would be fixed with this approach -- which is a
> downside.
> 
> All above are an idea for now.  Let me know if I should go further
> along with this, or there is already a better another approach.
> 
> (And the macros can be better named, sure :)
> 
> 
> thanks,
> 
> Takashi