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@xxxxxxxxxxxxx> 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-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
