linux-kernel - Re: [PATCH] powernow-k8: depend on acpi-processor for SMP systems

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: <464CCBCF.3010001@comcast.net>
Date:	Thu, 17 May 2007 17:40:31 -0400
From:	Ed Sweetman <safemode2@...cast.net>
To:	Dave Jones <davej@...hat.com>
CC:	Len Brown <lenb@...nel.org>, Daniel Drake <dsd@...too.org>,
	duaneg@...da.com, prakash@...noor.de, jhoblitt@....hawaii.edu,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] powernow-k8: depend on acpi-processor for SMP systems

Ed Sweetman wrote:
> Dave Jones wrote:
>> On Thu, May 17, 2007 at 02:13:42PM -0400, Len Brown wrote:
>>
>>  > > Index: linux/arch/i386/kernel/cpu/cpufreq/Kconfig
>>  > > ===================================================================
>>  > > --- linux.orig/arch/i386/kernel/cpu/cpufreq/Kconfig
>>  > > +++ linux/arch/i386/kernel/cpu/cpufreq/Kconfig
>>  > > @@ -81,6 +81,7 @@ config X86_POWERNOW_K7_ACPI
>>  > >  config X86_POWERNOW_K8
>>  > >      tristate "AMD Opteron/Athlon64 PowerNow!"
>>  > >      select CPU_FREQ_TABLE
>>  > > +    select ACPI_PROCESSOR if SMP
>>  > >      depends on EXPERIMENTAL
>>  > >      help
>>  > >        This adds the CPUFreq driver for mobile AMD 
>> Opteron/Athlon64 processors.
>>  >  > Unfortunately this patch will not actually enable 
>> ACPI_PROCESSOR in
>>  > the SMP=y ACPI=n case.  "select" doesn't work for targets that
>>  > have dependencies.
>>
>> I don't think we can fix this perfectly tbh, but the above at
>> least gets us close for the majority of users.
>>
>> Are there many x86-64 users that don't enable acpi ?
>>
>>     Dave
>>
>>   
> I've just always compiled acpi_processor in, it's only logical that if 
> you are using a power management feature, that you compile in the 
> power management interface, and if your stuff deals directly with the 
> cpu, you may want to compile the acpi_processor driver in.  The only 
> reason I knew to do that though, was because i go through each 
> option.  Someone else looking to just enable cpufreq, would skip the 
> sub-drivers of ACPI, and never know better. We dont suggest anywhere 
> in the cpufreq driver, we dont mention restrictions or limits of the 
> driver without acpi, and we certainly dont select it or make it 
> dependent (except silently and invisibly to the user).
> Every other cpufreq driver demands acpi.  In windows you have to have 
> acpi, the p states are called acpi p states everywhere.  The problem 
> here is that the author to the powernow_k8 driver found a way to get 
> some cpufreq functionality without acpi.
> So to make everyone happy, maybe we should have the silently 
> selected/deselected driver exposed to the user, as a sub-driver.
> ->  Powernow K8 / athlon64  cpufreq driver     y/m/n
> ------->    ACPI support      y/m/n
>

Here's a patch


View attachment "powernow.patch" of type "text/x-patch" (683 bytes)