linux-kernel - Re: [PATCH] PM / Runtime: Only force-resume device if it has been force-suspended

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]

Date:	Sun, 6 Mar 2016 11:59:07 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Laurent Pinchart <laurent.pinchart@...asonboard.com>
cc:	Ulf Hansson <ulf.hansson@...aro.org>,
	Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
	Kevin Hilman <khilman@...nel.org>,
	<linux-renesas-soc@...r.kernel.org>
Subject: Re: [PATCH] PM / Runtime: Only force-resume device if it has been
 force-suspended

On Sun, 6 Mar 2016, Laurent Pinchart wrote:

> > >> What I was thinking though, but it might be a bit controversial. :-)...
> > >> Instead of relying on whether we actually forced runtime suspend
> > >> earlier, why couldn't we instead check the runtime PM usage count of
> > >> the device?
> > >> 
> > >> Only when it's greater than zero, we shall do the forced resume of the
> > >> device, otherwise just re-enable runtime PM.
> > >> 
> > >> This would have the affect of leaving devices in runtime suspend,
> > >> until they really needs to be used again. It would thus decrease the
> > >> total system PM resume time.
> > >> 
> > >> Do you think this could work?
> > > 
> > > If you do this then there would be no need for is_force_suspended.  It
> > > seems like a good idea to me.
> > 
> > I agree, that's a better idea. Drivers shouldn't call
> > pm_runtime_force_resume() if they haven't called pm_runtime_force_suspend(),
> > so checking the PM use count should be fine. I'll modify the patch, test it
> > and resubmit.
> 
> I gave it an unfortunately unsuccessful try. The problem I ran into is that 
> device_prepare() calls pm_runtime_get_noresume() calls 
> pm_runtime_get_noresume(), with the corresponding pm_runtime_put() call being 
> performed in device_complete(). The device power usage_count is thus always 
> non-zero in the system resume handler, so I can't base the decision on that.

You could check for usage_count > 1 instead of > 0.  With a comment 
explaining why, of course.

Alan Stern

> I also noticed that pm_genpd_prepare() runtime-resumes the device (when the 
> power domain is in the GPD_STATE_ACTIVE state). I don't know why that is, but 
> it means that in practice my device gets runtime-resumed when suspending the 
> system while it could stay runtime-suspended in practice.