linux-kernel - Re: [linux-pm] Power Domain Framework

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] [day] [month] [year] [list]

Message-ID: <20100517031613.GA3130@opensource.wolfsonmicro.com>
Date:	Sun, 16 May 2010 20:16:16 -0700
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Sundar <sunder.svit@...il.com>
Cc:	Deepak Sikri <deepak.sikri79@...il.com>, viresh.kumar@...com,
	rajeev-dlh.kumar@...com, armando.visconti@...com,
	linux-kernel@...r.kernel.org, vipin.kumar@...com,
	shiraz.hashim@...com, linux-pm@...ts.linux-foundation.org,
	linus.walleij@...ricsson.com
Subject: Re: [linux-pm] Power Domain Framework

On Sun, May 16, 2010 at 04:43:52PM +0530, Sundar wrote:

Please don't top post, it breaks the thread of discussion.

> However, for working with power domains within the framework, I feel that,
> - support must be added to allow additional domain-specific states
> like retention, idle etc.

I'm really not convinced that this is a good idea.  Generally I suspect
the implementations of these concepts that I've seen would introduce
layering violations if done via the regulator API - from what I've seen
the power domains can end up knowing rather more about the things that
are being powered than is healthy for the regulator API and...

> - controlling operating points for regulators, unlike setting optimal modes.
> - controlling regulator modes via constraints enforced by clients and
> managing transition to various states through the client requests and
> pushing the client states up to the parent regulator.

...knowing a lot about the specifics of the internal structures of the
device you're trying to model.  Cross talk with the clock API also seems
fairly common here.

I do think it's likely that you'll want something that looks like the
regulator API at the edges, but that a separate implementation that
avoids having to shoehorn through the abstractions of the regulator API
for the on-chip work seems much more sensible (and is what OMAP and SH
are already doing).  This is fairly similar to the relationship between
the clock and regulator APIs - they look a lot alike, especially from a
user point of view, but they are separate because there are enough
differences in what they are trying to represent to make it sensible to
keep them apart.

However, if you have patches it's probably easier to talk about those
than architecture astronauting; perhaps your implementation avoids my
concerns.
--
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/