[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdVD7+GqgjhXEHYsema5uLPG4A4HANAKyGO2DSTnoskezA@mail.gmail.com>
Date: Thu, 27 Nov 2014 18:00:17 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: 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>,
Alan Stern <stern@...land.harvard.edu>,
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
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 ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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/
Powered by blists - more mailing lists