netdev - Re: [PATCH 8/8] net/iucv: Use the new device_to_pm() helper to access struct dev_pm

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAJZ5v0gTWaE_ehFg+JDpPEANiD-jr5P5D4LL2XpSiVzHZoZ-_g@mail.gmail.com>
Date:   Tue, 26 May 2020 18:06:24 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Krzysztof Wilczyński <kw@...ux.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Len Brown <lenb@...nel.org>, Kevin Hilman <khilman@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Pavel Machek <pavel@....cz>, Johan Hovold <johan@...nel.org>,
        Alex Elder <elder@...nel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Felipe Balbi <balbi@...nel.org>,
        Julian Wiedmann <jwi@...ux.ibm.com>,
        Karsten Graul <kgraul@...ux.ibm.com>,
        Ursula Braun <ubraun@...ux.ibm.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        John Stultz <john.stultz@...aro.org>,
        "David S. Miller" <davem@...emloft.net>,
        greybus-dev@...ts.linaro.org, netdev <netdev@...r.kernel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Linux PCI <linux-pci@...r.kernel.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        linux-s390@...r.kernel.org,
        "open list:TARGET SUBSYSTEM" <linux-scsi@...r.kernel.org>,
        "open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:" 
        <linux-usb@...r.kernel.org>
Subject: Re: [PATCH 8/8] net/iucv: Use the new device_to_pm() helper to access
 struct dev_pm_ops

On Tue, May 26, 2020 at 5:28 PM Alan Stern <stern@...land.harvard.edu> wrote:
>
> On Tue, May 26, 2020 at 05:19:07PM +0200, Rafael J. Wysocki wrote:
> > On Tue, May 26, 2020 at 5:07 PM Krzysztof Wilczyński <kw@...ux.com> wrote:
> > >
> > > Hello Greg,
> > >
> > > [...]
> > > > It's "interesting" how using your new helper doesn't actually make the
> > > > code smaller.  Perhaps it isn't a good helper function?
> > >
> > > The idea for the helper was inspired by the comment Dan made to Bjorn
> > > about Bjorn's change, as per:
> > >
> > >   https://lore.kernel.org/driverdev-devel/20191016135002.GA24678@kadam/
> > >
> > > It looked like a good idea to try to reduce the following:
> > >
> > >   dev->driver && dev->driver->pm && dev->driver->pm->prepare
> > >
> > > Into something more succinct.  Albeit, given the feedback from yourself
> > > and Rafael, I gather that this helper is not really a good addition.
> >
> > IMO it could be used for reducing code duplication like you did in the
> > PCI code, but not necessarily in the other places where the code in
> > question is not exactly duplicated.
>
> The code could be a little more succinct, although it wouldn't fit every
> usage.  For example,
>
> #define pm_do_callback(dev, method) \
>         (dev->driver && dev->driver->pm && dev->driver->pm->callback ? \
>         dev->driver->pm->callback(dev) : 0)
>
> Then the usage is something like:
>
>         ret = pm_do_callback(dev, prepare);
>
> Would this be an overall improvement?

It wouldn't cover all of the use cases.

For example, PCI does other things in addition to running a callback
when it is present.

Something like this might be enough though:

#define pm_driver_callback_is_present(dev, method) \
        (dev->driver && dev->driver->pm && dev->driver->pm->method)

#define pm_run_driver_callback(dev, method) \
        (pm_driver_callback_is_present(dev, method) ?
dev->driver->pm->method(dev) : 0)

#define pm_get_driver_callback(dev, method) \
        (pm_driver_callback_is_present(dev, method) ?
dev->driver->pm->method : NULL)

so whoever needs the callback pointer can use pm_get_driver_callback()
and whoever only needs to run the callback can use
pm_run_driver_callback().

Cheers!