linux-kernel - Re: [PATCH] PM / domains: Kconfig: always enable 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: <7hk32x8zg2.fsf@deeprootsystems.com>
Date:	Fri, 14 Nov 2014 09:27:41 -0800
From:	Kevin Hilman <khilman@...nel.org>
To:	Ulf Hansson <ulf.hansson@...aro.org>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	"linux-pm\@vger.kernel.org" <linux-pm@...r.kernel.org>,
	linaro-kernel <linaro-kernel@...ts.linaro.org>,
	Grygorii Strashko <grygorii.strashko@...com>,
	Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
	open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled

Hi Ulf,

Ulf Hansson <ulf.hansson@...aro.org> writes:

> On 13 November 2014 23:28, Kevin Hilman <khilman@...nel.org> wrote:
>> From: Kevin Hilman <khilman@...aro.org>
>>
>> It makes little sense to use generic power domains without runtime PM.
>> Also, since the complexities of handling the !PM_RUNTIME case are
>> causing more trouble and confusion than they're worth, let's simplify
>> the world by making genpd always enable runtime PM.
>
> I do agree that your above statement seems reasonable, even if can't
> really tell if that would break some SOCs use-cases.

Break in what way?

> My concern is though, that I fear we will be taking short-cuts in
> genpd that might bite us later on, but I might be wrong.
>
> The reason for my concern is that on every other place, like in the
> subsystem level, driver core, PM core and of course in drivers -  we
> need to cope with all the combinations of CONFIG_PM_SLEEP and
> CONFIG_PM_SLEEP.  So theoretically, why shouldn't genpd be able to do
> that as well?

Good question, and one we need to figure out.  (I meant to mark this
patch as RFC for that reason.)

I think the primary question is: why would one want to use genpd without
runtime PM?

I understand why one might want to use/test drivers with various
combinations of PM_SLEEP and PM_RUNTIME, but I'm not seeing why we
should need to support genpd without PM_RUNTIME enabled.

In fact, on all the SoCs I've worked closely with, power domains,
suspend/resume and runtime PM are all so closely intertwined that I
can't imagine a useful scenario where they they are not all used
together.  If you care about PM, you turn them all on.  If you don't,
you turn them all off and ensure everything is enabled at boot.

IMO, we're spending a lot of cycles supporting these various
combinations and permutations and as a result are not really able to
solve the real problems people are raising.

Seems like most of the time a new feature/fixup/cleanup is proposed, the
discussion always ends up around how to support things when this or that
option is disabled, or some combination of kconfig options that weren't
considered.

I think we should simplify the config space permuations so we can focus
on improving the frameworks.

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