linux-kernel - Re: [PATCH] PM: Document rules on using pm_runtime

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]

Date:   Thu, 21 Sep 2017 16:44:20 +0200
From:   "Rafael J. Wysocki" <rjw@...ysocki.net>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     Johannes Stezenbach <js@...21.net>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Kevin Hilman <khilman@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] PM: Document rules on using pm_runtime_resume() in system suspend callbacks

On Thursday, September 21, 2017 4:36:30 PM CEST Alan Stern wrote:
> On Thu, 21 Sep 2017, Johannes Stezenbach wrote:
> 
> > On Thu, Sep 21, 2017 at 02:39:30AM +0200, Rafael J. Wysocki wrote:
> > > On Wed, Sep 20, 2017 at 6:27 PM, Johannes Stezenbach <js@...21.net> wrote:
> > > >
> > > >  E.g. an audio codec could keep running
> > > > while the i2c bus used to program its registers can be runtime suspended.
> > > > If this is correct I think it would be useful to spell it out explicitly
> > > > in the documentation.
> > > 
> > > That's because the i2c bus uses the ignore_children flag that allows
> > > it to override the general rules. :-)
> > 
> > Ah!  I was looking at Documentation/driver-api/pm only (which is
> > changed by your patch), but this is documented in Documentation/power
> > (and obviously I hadn't checked the code, shame on me).
> > 
> > > direct_complete has nothing to do with this.
> > 
> > Oh?  Reading again, do I get this right:
> > 
> > 1. simple method: always call pm_runtime_resume() in ->suspend(),
> >    then suspend the driver again
> > 2. optimization: if pm_runtime_suspended(), the driver's ->suspend()
> >    can possibly do nothing if conditions permit, otherwise it calls
> >    pm_runtime_resume() and then suspends
> > 3. optimization: tell pm core to skip ->suspend() via return value
> >    from ->prepare() which sets direct_complete
> > 
> > ...and your patch only deals with 1 and 2.
> > 
> > Sorry to hijack your thread for side discussion, it was
> > inadvertant due to my lack of understanding.
> > 
> > 
> > > First off, the PM core does check the direct_complete flag in
> > > __device_suspend() and does more-or-less what you are saying.
> > > 
> > > However, that flag is initialized in device_prepare() with the help of
> > > the ->suspend() return value, because whether or not it makes sense to
> > 
> > you mean ->prepare(), right?
> > 
> > > set that flag depends on some conditions that may change between
> > > consecutive system suspend-resume cycles in general and need to be
> > > checked in advance before setting it.
> > > 
> > > HTH
> > 
> > It does, however the question remains *why* it needs to check
> > it in ->prepare() and not right before calling ->suspend().
> > Using ->prepare() for the purpose seems wrong since it traverses
> > the hierarchy in the "wrong" order.
> 
> No, it is the _right_ order.  If a device's ->prepare() says that
> direct_complete is okay, but one of its descendants disallows
> direct_complete, we then want to clear the direct_complete flag in the
> original device structure.  We couldn't do this if we checked the 
> descendant's driver first.

But we really clear it for parents (and suppliers) in __device_suspend(),
which is still OK, because that is first called for the children (and
consumers).  So the ordering of ->prepare() doesn't really matter here IMO.

Thanks,
Rafael