linux-kernel - Re: [2.6.21-rc3] cpufreq: p4-clockmod.c compilation error

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: <20070307065458.GA15453@redhat.com>
Date:	Wed, 7 Mar 2007 01:54:58 -0500
From:	Dave Jones <davej@...hat.com>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Dominik Brodowski <linux@...do.de>, linux-kernel@...r.kernel.org
Subject: Re: [2.6.21-rc3] cpufreq: p4-clockmod.c compilation error

On Tue, Mar 06, 2007 at 10:33:05PM -0800, David Rientjes wrote:
 > arch/x86_64/kernel/built-in.o: In function `cpufreq_p4_verify':p4-clockmod.c:(.text.cpufreq_p4_verify+0x8): undefined reference to `cpufreq_frequency_table_verify'
 > arch/x86_64/kernel/built-in.o: In function `cpufreq_p4_cpu_exit':p4-clockmod.c:(.text.cpufreq_p4_cpu_exit+0x8): undefined reference to `cpufreq_frequency_table_put_attr'
 > arch/x86_64/kernel/built-in.o: In function `cpufreq_p4_cpu_init':p4-clockmod.c:(.text.cpufreq_p4_cpu_init+0x13b): undefined reference to `cpufreq_frequency_table_get_attr'
 > :p4-clockmod.c:(.text.cpufreq_p4_cpu_init+0x163): undefined reference to `cpufreq_frequency_table_cpuinfo'
 > arch/x86_64/kernel/built-in.o: In function `cpufreq_p4_target':p4-clockmod.c:(.text.cpufreq_p4_target+0x21): undefined reference to `cpufreq_frequency_table_target'
 > arch/x86_64/kernel/built-in.o: In function `k8nops':alternative.c:(.data+0x2b70): undefined reference to `cpufreq_freq_attr_scaling_available_freqs'

 > CONFIG_CPU_FREQ=y
 > CONFIG_CPU_FREQ_TABLE=m

 > CONFIG_X86_P4_CLOCKMOD=y

So P4_CLOCKMOD does a 'select CPU_FREQ_TABLE', but for some reason, that makes it =m,
not the same as whatever the option that is doing the 'select' is set to
(which is what I thought it did).

Given the cpufreq table code is tiny anyway, I'm wondering if its worth the
pain of having it be modular, instead just making it be built-in to cpufreq.

Give the diff below a shot?

	Dave

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index d155e81..74747d9 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -16,7 +16,7 @@ config CPU_FREQ
 if CPU_FREQ
 
 config CPU_FREQ_TABLE
-       tristate
+       bool
 
 config CPU_FREQ_DEBUG
        bool "Enable CPUfreq debugging"


-- 
http://www.codemonkey.org.uk
-
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/