linux-kernel - Re: Power Management framework proposal

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: <Pine.LNX.4.64.0707241556140.6590@asgard.lang.hm>
Date:	Tue, 24 Jul 2007 16:02:46 -0700 (PDT)
From:	david@...g.hm
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
cc:	Arjan van de Ven <arjan@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-pm <linux-pm@...ts.linux-foundation.org>
Subject: Re: Power Management framework proposal

On Wed, 25 Jul 2007, Benjamin Herrenschmidt wrote:

> On Tue, 2007-07-24 at 13:14 -0700, david@...g.hm wrote:
>>> I think we need a set of constraints that trickle down the power
>> tree
>>> and limit what a given driver can do locally.
>>
>> what sort of contraints are you thinking of?
>
> A parent power state defines what states children can be in. For
> example. A way to express those dependencies would be nice. Or
> alternatiely, the power state of all the children defines the power
> state a parent can go in automatically.

Ok, I see tow things here.

1. do you really want to try and propogate things like this from one to 
the other, or would it be good enough to flag the issue and let the 
software selecting the modes implement this contraint?

2. how can you standardize the requirements?

at the very least you have

for this mode all children must be off

for this mode all children must be in a mode that includes a 'suspended' 
flag (this could be made implicit by saying that you must suspend children 
before parents) and then just flagging the 'suspended, but not off' modes)

what requirements are needed? (I'm sure that there are others, but 
hopefully it's possible to avoid requirements like 'the clock speed for 
device A must be >X to allow device B to operate in mode Y')

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