[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87ikhptpgm.wl-tiwai@suse.de>
Date: Thu, 11 Sep 2025 09:31:37 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Rafael J. Wysocki <rafael@...nel.org>
Cc: linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: PM runtime auto-cleanup macros
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
Powered by blists - more mailing lists