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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
