linux-kernel - Re: [PATCH v1 2/3] PCI/sysfs: Use PM runtime class macro for auto cleanup in reset_method

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0gnqoJ8bALZT61ZvTA=chp8y5QBiA7ZpNQ6fFJuQzZUnA@mail.gmail.com>
Date: Fri, 26 Sep 2025 16:36:52 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Jonathan Cameron <jonathan.cameron@...wei.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Linux PM <linux-pm@...r.kernel.org>, 
	LKML <linux-kernel@...r.kernel.org>, Linux PCI <linux-pci@...r.kernel.org>, 
	Alex Williamson <alex.williamson@...hat.com>, Bjorn Helgaas <helgaas@...nel.org>, 
	Takashi Iwai <tiwai@...e.de>, Zhang Qilong <zhangqilong3@...wei.com>, 
	Ulf Hansson <ulf.hansson@...aro.org>, Dan Williams <dan.j.williams@...el.com>
Subject: Re: [PATCH v1 2/3] PCI/sysfs: Use PM runtime class macro for auto
 cleanup in reset_method_store()

On Fri, Sep 26, 2025 at 3:49 PM Jonathan Cameron
<jonathan.cameron@...wei.com> wrote:
>
> On Fri, 19 Sep 2025 18:38:42 +0200
> "Rafael J. Wysocki" <rafael@...nel.org> wrote:
>
> > From: Takashi Iwai <tiwai@...e.de>
> >
> > The newly introduced class macro can simplify the code.
> >
> > Also, add the proper error handling for the PM runtime get.
> >
> > Signed-off-by: Takashi Iwai <tiwai@...e.de>
> > [ rjw: Adjust subject and error handling ]
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > ---
> >  drivers/pci/pci-sysfs.c |    5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > --- a/drivers/pci/pci-sysfs.c
> > +++ b/drivers/pci/pci-sysfs.c
> > @@ -1475,8 +1475,9 @@ static ssize_t reset_method_store(struct
> >               return count;
> >       }
> >
> > -     pm_runtime_get_sync(dev);
> > -     struct device *pmdev __free(pm_runtime_put) = dev;
> > +     CLASS(pm_runtime_resume_and_get, pmdev)(dev);
> > +     if (IS_ERR(pmdev))
> > +             return -ENXIO;
> Hi Rafael,
>
> Why this approach rather than treating runtime pm state like a conditional
> lock (we use it much like one) and using ACQUIRE() / ACQUIRE_ERR()?

Mostly because devices are not locks.

> Ultimately that's a wrapper around the same infrastructure but
> perhaps neater as it removes need to have that explicit magic pmdev.

You'll need to have a magic pmdev or similar regardless IIUC.

Say there is

DEFINE_GUARD(pm_runtime_active, struct device *,
pm_runtime_get_sync(_T), pm_runtime_put(_T))
DEFINE_GUARD_COND(pm_runtime_active, _try, pm_runtime_resume_and_get(_T))

so the user of this will do

ACQUIRE(pm_runtime_active_try, pm)(dev);
if (ACQUIRE_ERR(pm_runtime_active_try, &pm))
        return -ENXIO;

and there's a "magic" pm though pm is not a struct device pointer.

Maybe it's nicer.  I guess people may be more used to dealing with int
error variables.

Let me try this and see how far I can get with this.

> +CC Dan as he can probably remember the discussions around ACQUIRE()
> vs the way you have here better than I can.
>
> In general great that you've done this.  Was on my list too, but I didn't
> get around to actually spinning the patches!   This is going to be
> very useful indeed.

Thanks!