linux-kernel - Re: [PATCH v3 2/2] PM / Runtime: Add pm_runtime_enable

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:	Tue, 7 Jul 2015 10:55:59 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
cc:	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Kevin Hilman <khilman@...aro.org>,
	Russell King <rmk+kernel@....linux.org.uk>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 2/2] PM / Runtime: Add pm_runtime_enable_recursive

On Tue, 7 Jul 2015, Rafael J. Wysocki wrote:

> > > All right, we can make a decision and document it.  The following seems
> > > reasonable to me:
> > > 
> > > 	If dev->power.direct_complete is set then the PM core will
> > > 	assume that dev->power.rpm_status is accurate even when
> > > 	dev->power.disable_depth > 0.  The core will obey the
> > > 	.direct_complete setting regardless of .disable_depth.
> > > 
> > > 	As a consequence, devices that support system sleep but don't 
> > > 	support runtime PM must _never_ have .direct_complete set.
> > > 
> > > 	On the other hand, if a device (such as a "virtual" device)
> > > 	requires no callbacks for either system sleep or runtime PM, 
> > > 	then there is no harm in setting .direct_complete.  Indeed,
> > > 	doing so may help speed up an ancestor device's sleep
> > > 	transition.
> > > 
> > > How does that sound?
> > 
> > It would be workable I think, but I'd prefer the core to be told directly
> > about devices whose runtime PM status doesn't matter (because nothing changes
> > between "suspended" and "active"), so they may be treated in a special way
> > safely.
> > 
> > If we had that information, no special rules other than "that is a device
> > whose runtime PM status doesn't matter, so treat it accordingly" would be
> > necessary.
> 
> That said, a situation to consider is when device X is just a software device,
> but it has children that correspond to physical hardware.  If that is the case,
> the usual parent-children rules should apply to X and its children (ie. X should
> only be marked as "suspended" if all of its children are suspended) and I see
> no reason why the parent-children rules for direct_resume should not apply here.

Yes, this illustrates that in some ways we must not treat "virtual" or 
"software" devices specially.  Being "virtual" is not the same as 
having the ignore_children flag set.

The change I'm proposing is not related to whether a device is 
"virtual".  I'm just suggesting that the normal direct_complete rules 
should apply even when devices are runtime-PM-disabled.

This doesn't mean that their runtime PM status doesn't matter.  Just
the opposite, in fact -- it means that the PM core should pay attention
to the runtime PM status during a sleep transition even though
disabled_depth > 0.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/