Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210528091202.11603-1-ulf.hansson@linaro.org> <20210528152719.GA1473569@rowland.harvard.edu>
In-Reply-To: <20210528152719.GA1473569@rowland.harvard.edu>
From:   Ulf Hansson <ulf.hansson@linaro.org>
Date:   Mon, 31 May 2021 09:08:08 +0200
Message-ID: <CAPDyKFp14pnSsaV3bnbW2FVTbtqTb5z39nZ0+NQM0YRv00W4JQ@mail.gmail.com>
Subject: Re: [PATCH 2/2] PM: runtime: Allow unassigned ->runtime_suspend|resume
 callbacks
To:     Alan Stern <stern@rowland.harvard.edu>
Cc:     "Rafael J . Wysocki" <rjw@rjwysocki.net>,
        Linux PM <linux-pm@vger.kernel.org>,
        Saravana Kannan <saravanak@google.com>,
        Adrian Hunter <adrian.hunter@intel.com>,
        Tony Lindgren <tony@atomide.com>,
        Kevin Hilman <khilman@kernel.org>,
        Geert Uytterhoeven <geert+renesas@glider.be>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, 28 May 2021 at 17:27, Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Fri, May 28, 2021 at 11:12:02AM +0200, Ulf Hansson wrote:
> > We are currently allowing ->rpm_idle() callbacks to be unassigned without
> > returning an error code from rpm_idle(). This has been useful to avoid
> > boilerplate code in drivers. Let's take this approach a step further, by
> > allowing unassigned ->runtime_suspend|resume() callbacks as well.
> >
> > In this way, a consumer/supplier device link can be used to let a consumer
> > device be power managed through its supplier device, without requiring
> > assigned ->runtime_suspend|resume() callbacks for the consumer device, for
> > example.
> >
> > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> > ---
> >  drivers/base/power/runtime.c | 8 +++-----
> >  1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> > index 68bebbf81347..8a66eaf731e4 100644
> > --- a/drivers/base/power/runtime.c
> > +++ b/drivers/base/power/runtime.c
> > @@ -345,7 +345,7 @@ static void rpm_suspend_suppliers(struct device *dev)
> >  static int __rpm_callback(int (*cb)(struct device *), struct device *dev)
> >       __releases(&dev->power.lock) __acquires(&dev->power.lock)
> >  {
> > -     int retval, idx;
> > +     int retval = 0, idx;
> >       bool use_links = dev->power.links_count > 0;
> >
> >       if (dev->power.irq_safe) {
> > @@ -373,7 +373,8 @@ static int __rpm_callback(int (*cb)(struct device *), struct device *dev)
> >               }
> >       }
> >
> > -     retval = cb(dev);
> > +     if (cb)
> > +             retval = cb(dev);
> >
> >       if (dev->power.irq_safe) {
> >               spin_lock(&dev->power.lock);
> > @@ -484,9 +485,6 @@ static int rpm_callback(int (*cb)(struct device *), struct device *dev)
> >  {
> >       int retval;
> >
> > -     if (!cb)
> > -             return -ENOSYS;
>
> This is a change in behavior, right?  What about drivers or subsystems
> that don't support runtime PM and consequently don't have any RPM
> callbacks assigned?

Yes, you are right.

However, drivers/subsystems that support runtime PM should also call
pm_runtime_enable() and if they don't, the rpm_callback() should not
get called for them.

Then, at least to me, I think it would be quite odd that a
subsystem/driver that calls pm_runtime_enable(), would be checking
return values from pm_runtime_get|put_*() for -ENOSYS? I mean, why
bother calling pm_runtime_enable() in the first place?

>
> Also, assuming Rafael accepts this change, don't you also need to update
> the runtime-PM documentation?

Good point, thanks! Let me add a patch updating the docs.

>
> Alan Stern
>

Kind regards
Uffe