Messages in this thread Patch in this message | | | Date | Wed, 8 Nov 2006 19:09:44 -0800 | From | Randy Dunlap <> | Subject | [PATCH] cpufreq: select consistently (Re: 2.6.19-rc5-mm1) |
| |
On Wed, 8 Nov 2006 15:15:39 -0500 Dave Jones wrote:
> On Wed, Nov 08, 2006 at 12:05:47PM -0800, Andrew Morton wrote: > > > The problem is that you have > > > > > CONFIG_CPU_FREQ_TABLE=m > > > CONFIG_X86_ACPI_CPUFREQ=y > > > > but acpi-cpufreq needs the stuff in freq_table.c. > > > > This happens again and again and again and again. I wish people would just > > stop using `select'. It. Doesn't. Work. > > > > Either we fix select or we stop using the damn thing. > > So, why doesn't select set the symbol it's selecting to the > same value as the symbol being configured ? > That would solve the issue no?
Why does arch/i386/kernel/cpu/cpufreq/Kconfig say:
config X86_ACPI_CPUFREQ tristate "ACPI Processor P-States driver" select CPU_FREQ_TABLE depends on ACPI_PROCESSOR
but arch/x86_64/kernel/cpufreq/Kconfig say:
config X86_ACPI_CPUFREQ tristate "ACPI Processor P-States driver" depends on ACPI_PROCESSOR
# NOTE: no "select" on the latter one. // Randy
Let's see. Does that one-line patch fix anything? <builds>
make oldconfig
< CONFIG_CPU_FREQ_TABLE=m > CONFIG_CPU_FREQ_TABLE=y
Builds cleanly now.
--- From: Randy Dunlap <randy.dunlap@oracle.com>
Make x86_64 ACPI_CPU_FREQ select CPU_FREQ_TABLE like other methods do. (although we should still eliminate as much use of 'select' as possible)
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> --- arch/x86_64/kernel/cpufreq/Kconfig | 1 + 1 file changed, 1 insertion(+)
--- linux-2.6.19-rc5-mm1.orig/arch/x86_64/kernel/cpufreq/Kconfig +++ linux-2.6.19-rc5-mm1/arch/x86_64/kernel/cpufreq/Kconfig @@ -49,6 +49,7 @@ config X86_SPEEDSTEP_CENTRINO_ACPI config X86_ACPI_CPUFREQ tristate "ACPI Processor P-States driver" + select CPU_FREQ_TABLE depends on ACPI_PROCESSOR help This driver adds a CPUFreq driver which utilizes the ACPI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |