[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110208164822.GA7426@linux-sh.org>
Date: Wed, 9 Feb 2011 01:48:22 +0900
From: Paul Mundt <lethal@...ux-sh.org>
To: "Rafael J. Wysocki" <rjw@...k.pl>
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>,
Mark Brown <broonie@...nsource.wolfsonmicro.com>,
Len Brown <len.brown@...el.com>,
Alan Stern <stern@...land.harvard.edu>,
linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
linux-embedded@...r.kernel.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] PM: Hide CONFIG_PM from users
On Tue, Feb 08, 2011 at 12:05:40AM +0100, Rafael J. Wysocki wrote:
> On Monday, February 07, 2011, Dmitry Torokhov wrote:
> > More of an observation for your (b) justification. I'd probably force
> > CONFIG_PM to always 'y'w while we weeding references to it from
> > drivers...
>
> We simply can't force CONFIG_PM to 'y', because some platforms want it to be 'n'.
>
> OTOH, if CONFIG_PM = CONFIG_PM_SLEEP||CONFIG_PM_RUNTIME, we can just leave the
> #ifdefs as they are and simply avoid adding new ones, or use CONFIG_PM for all
> PM callbacks.
>
For sh at least turning on CONFIG_PM without PM_SLEEP or PM_RUNTIME is
largely pointless, so the bulk of the defconfigs have it turned off. The
few platforms that do use CONFIG_PM for something also have more
comprehensive support implemented. The few times we do have it enabled
without one of the others supported is simply for build coverage, mostly
due to sharing drivers (whatever isn't already triggered through
rand/allyes/modconfigs).
I would expect that this is a common scenario for the bulk of the
defconfigs that reflect PM being a platform-specific vs architecture-wide
property regardless of architecture, however.
--
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