linux-kernel - Re: [RFC] CPUFreq PowerOP integration, Intro 0/3

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: <20061007031933.GC1494@dominikbrodowski.de>
Date:	Fri, 6 Oct 2006 23:19:33 -0400
From:	Dominik Brodowski <linux@...inikbrodowski.net>
To:	"Eugeny S. Mints" <eugeny.mints@...il.com>
Cc:	pm list <linux-pm@...ts.osdl.org>,
	Matthew Locke <matt@...adgs.com>,
	Amit Kucheria <amit.kucheria@...ia.com>,
	Igor Stoppa <igor.stoppa@...ia.com>,
	kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] CPUFreq PowerOP integration, Intro 0/3

Hi,

Just some nitpicking at the description, will cover the patches next.

On Thu, Sep 14, 2006 at 06:42:26PM +0400, Eugeny S. Mints wrote:
> Integrating CPUFreq and PowerOP was discussed at the Linux PM summit
> and in recent emails exchanges.  Some say keep them separate and some
> say they must be integrated.  There is actually a very natural point
> where integration makes sense - cpufreq_driver.

Well, I don't think that cpufreq_driver is the "natural" point -- in fact,
I think it is one of the worst points for the interaction. My alternative
suggestion will be the last one of the many mails you'll likely receive from
me today :)

> The patches do not change the functionality of the cpufreq core.
> Instead the idea is to redesign the tightly coupled interfaces of
> cpufreq to clearly separate the arch dependent and independent pieces
> layers.  This enables cpufreq to become arch independent and can start
> to use the named operating points in all its layers.

cpufreq is arch independent, as can be seen that it is used by many
different architectures right now.

> cpufreq.c
> - get rid of cpufreq driver calls. the calls are replaced be calls to arch
> independent freq_helpers (freq_helpers.c)

Have you considered the drivers which do not use the frequency table helper
library in cpufreq?

> - available frequencies sysfs interface now can be handled in arch 
> independent way

Also for the case where there are thousands of frequency states? Or only a
range to be set, and a in-CPU-mode [longrun]? There's a reason this export
is optional.

> - cpufreq_sysdev_driver now serves only cpufreq core internal needs upon cpu
> add/remove events (since all hw related is handled by PM Core)

That sounds like a good step forward -- especially as sysdevs may actually
be removed soon. It's orthogonal to the other changes though; i.e. we could
do that with the current cpufreq core without switching to PowerOP/"PM
core".

> freq_table.c (now freq_helpers.c)
> - get rid of cpufreq_frequency_table structures as input parameter and made 
> the code arch independent by leveraging PowerOP interface

arch independent? Well, this helper library is used by different archs already...

Thanks,
	Dominik
-
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/