linux-kernel - Re: [PATCH 0/4] PM: Use CONFIG_PM instead of CONFIG_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: <1803282.Wzz7IausxS@vostro.rjw.lan>
Date:	Thu, 27 Nov 2014 22:35:15 +0100
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Linux PM list <linux-pm@...r.kernel.org>,
	Linux PCI <linux-pci@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Kevin Hilman <khilman@...nel.org>
Subject: Re: [PATCH 0/4] PM: Use CONFIG_PM instead of CONFIG_PM_RUNTIME in core code

On Thursday, November 27, 2014 12:18:23 PM Alan Stern wrote:
> On Thu, 27 Nov 2014, Geert Uytterhoeven wrote:
> 
> > Hi Rafael,
> > 
> > On Thu, Nov 27, 2014 at 5:52 PM, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
> > >> I have also tested the two Kconfig options; CONFIG_PM_SLEEP (which
> > >> selects CONFIG_PM_RUNTIME) and for CONFIG_PM_RUNTIME (with
> > >> CONFIG_PM_SLEEP unset).
> > >>
> > >> That brings me to a raise a question; why do we need to keep these two
> > >> configurations options? Couldn't we also have CONFIG_PM_RUNTIME to
> > >> select CONFIG_PM_SLEEP, that will further simplify things?
> > >
> > > My plan is different.  I'm going to eliminate PM_RUNTIME from the code
> > > and then replace it with PM as a selectable option.  Then, PM_SLEEP will
> > > select PM (directly) and PM_RUNTIME can be entirely dropped.
> > 
> > What's your rationale for keeping PM_SLEEP, and not consolidating both
> > PM_RUNTIME and PM_SLEEP into PM? I.e. what am I missing, still
> > considering myself a PM newbie?
> > 
> > > So in the end we'll have one Kconfig option less, which is a win IMO.
> > 
> > Having two less may be a bigger win ;-)
> 
> I imagine that Rafael would like to continue supporting platforms that 
> want to have runtime power management but not suspend or hibernation.  
> A number of embedded systems might fall into this category.

Right.

That said whether or not it is ever useful to set PM_RUNTIME alone is a good
question.  In my opinion it is useful today, at least on some platforms that
don't really support system suspend or hibernation in any form.  However, it
may not be the case any more when suspend-to-idle becomes mature enough,
because that should just work for any platform without any kind of special
support.  We're still missing some timekeeping bits there, but once that
gap has been covered, we may just eliminate PM_SLEEP as well if there's a
broad consensus on that.

Rafael

--
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/