[PATCH 0/3] cpufreq / linux-next build fixes

[PATCH 0/3] cpufreq / linux-next build fixes

[Alex Chiang]

Hi Dave,

I tripped over a build error when building /without/ CONFIG_CPU_FREQ.

I found this by way of the mmotm tree which I think sucks in linux-next.
I haven't checked your cpufreq tree directly, so apologies if these are
already fixed...

I build tested my changes with both CONFIG_CPU_FREQ set and unset, and
looked at the sparse output too, and all seems to be well. I did not
run-time test these changes.

Thanks,
/ac

---

Alex Chiang (3):
      [CPUFREQ] make ACPI P-state cpufreq drivers depend on CONFIG_CPU_FREQ
      ACPI: do not define acpi_processor_get_bios_limit() in processor.h
      [CPUFREQ] make internal cpufreq_add_dev_* static


 arch/x86/kernel/cpu/cpufreq/Kconfig |    6 +++---
 drivers/cpufreq/cpufreq.c           |    6 +++---
 include/acpi/processor.h            |    5 -----
 3 files changed, 6 insertions(+), 11 deletions(-)

[PATCH 1/3] [CPUFREQ] make ACPI P-state cpufreq drivers depend on CONFIG_CPU_FREQ

[Alex Chiang]

In menuconfig, if you do not select:

Power management and ACPI options ->
  CPU Frequency scaling -->
    CPU Frequency scaling

You do not get a chance to select the various CPUFreq processor drivers
either.

So, it seems reasonable to make these processor drivers:

	- powernow-k8
	- powernow-k7
	- acpi-cpufreq

depend upon CONFIG_CPU_FREQ. This change allows us to be smarter with
#ifdefs and symbols in generic ACPI header files later on.

Signed-off-by: Alex Chiang <achiang@hp.com>
---

 arch/x86/kernel/cpu/cpufreq/Kconfig |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/cpu/cpufreq/Kconfig b/arch/x86/kernel/cpu/cpufreq/Kconfig
index f138c6c..ca40a9f 100644
--- a/arch/x86/kernel/cpu/cpufreq/Kconfig
+++ b/arch/x86/kernel/cpu/cpufreq/Kconfig
@@ -13,7 +13,7 @@ comment "CPUFreq processor drivers"
 config X86_ACPI_CPUFREQ
 	tristate "ACPI Processor P-States driver"
 	select CPU_FREQ_TABLE
-	depends on ACPI_PROCESSOR
+	depends on ACPI_PROCESSOR && CPU_FREQ
 	help
 	  This driver adds a CPUFreq driver which utilizes the ACPI
 	  Processor Performance States.
@@ -69,7 +69,7 @@ config X86_POWERNOW_K6
 config X86_POWERNOW_K7
 	tristate "AMD Mobile Athlon/Duron PowerNow!"
 	select CPU_FREQ_TABLE
-	depends on X86_32
+	depends on X86_32 && CPU_FREQ
 	help
 	  This adds the CPUFreq driver for mobile AMD K7 mobile processors.
 
@@ -87,7 +87,7 @@ config X86_POWERNOW_K7_ACPI
 config X86_POWERNOW_K8
 	tristate "AMD Opteron/Athlon64 PowerNow!"
 	select CPU_FREQ_TABLE
-	depends on ACPI && ACPI_PROCESSOR
+	depends on ACPI && ACPI_PROCESSOR && CPU_FREQ
 	help
 	  This adds the CPUFreq driver for K8/K10 Opteron/Athlon64 processors.
 

[PATCH 2/3] ACPI: do not define acpi_processor_get_bios_limit() in processor.h

[Alex Chiang]

If we provide a definition for acpi_processor_get_bios_limit(), we will
encounter build errors (multiple definitions of the function) when we
do not have CONFIG_CPU_FREQ configured.

We've already changed the modules that depend on this function to only
get built when CONFIG_CPU_FREQ is configured, so removing the definition
when unconfigured is safe.

Cc: Thomas Renninger <trenn@suse.de>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Alex Chiang <achiang@hp.com>
---

 include/acpi/processor.h |    5 -----
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index c94f9f0..9db2159 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -318,11 +318,6 @@ static inline int acpi_processor_ppc_has_changed(struct acpi_processor *pr,
 	}
 	return 0;
 }
-int acpi_processor_get_bios_limit(int cpu, unsigned int *limit)
-{
-	return -ENODEV;
-}
-
 #endif				/* CONFIG_CPU_FREQ */
 
 /* in processor_throttling.c */

[PATCH 3/3] [CPUFREQ] make internal cpufreq_add_dev_* static

[Alex Chiang]

No need to export these symbols; make them static.

	cpufreq_add_dev_policy
	cpufreq_add_dev_symlink
	cpufreq_add_dev_interface

Signed-off-by: Alex Chiang <achiang@hp.com>
---

 drivers/cpufreq/cpufreq.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 0315069..e690211 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -783,7 +783,7 @@ static struct kobj_type ktype_cpufreq = {
  *   0:        Success
  *   Positive: When we have a managed CPU and the sysfs got symlinked
  */
-int cpufreq_add_dev_policy(unsigned int cpu, struct cpufreq_policy *policy,
+static int cpufreq_add_dev_policy(unsigned int cpu, struct cpufreq_policy *policy,
 		struct sys_device *sys_dev)
 {
 	int ret = 0;
@@ -858,7 +858,7 @@ int cpufreq_add_dev_policy(unsigned int cpu, struct cpufreq_policy *policy,
 
 
 /* symlink affected CPUs */
-int cpufreq_add_dev_symlink(unsigned int cpu, struct cpufreq_policy *policy)
+static int cpufreq_add_dev_symlink(unsigned int cpu, struct cpufreq_policy *policy)
 {
 	unsigned int j;
 	int ret = 0;
@@ -885,7 +885,7 @@ int cpufreq_add_dev_symlink(unsigned int cpu, struct cpufreq_policy *policy)
 	return ret;
 }
 
-int cpufreq_add_dev_interface(unsigned int cpu, struct cpufreq_policy *policy,
+static int cpufreq_add_dev_interface(unsigned int cpu, struct cpufreq_policy *policy,
 		struct sys_device *sys_dev)
 {
 	struct cpufreq_policy new_policy;

Re: [PATCH 1/3] [CPUFREQ] make ACPI P-state cpufreq drivers depend on CONFIG_CPU_FREQ

[Dave Jones]

 > diff --git a/arch/x86/kernel/cpu/cpufreq/Kconfig b/arch/x86/kernel/cpu/cpufreq/Kconfig
 > index f138c6c..ca40a9f 100644
 > --- a/arch/x86/kernel/cpu/cpufreq/Kconfig
 > +++ b/arch/x86/kernel/cpu/cpufreq/Kconfig
 > @@ -13,7 +13,7 @@ comment "CPUFreq processor drivers"
 >  config X86_ACPI_CPUFREQ
 >  	tristate "ACPI Processor P-States driver"
 >  	select CPU_FREQ_TABLE
 > -	depends on ACPI_PROCESSOR
 > +	depends on ACPI_PROCESSOR && CPU_FREQ
 >  	help
 >  	  This driver adds a CPUFreq driver which utilizes the ACPI
 >  	  Processor Performance States.
 > @@ -69,7 +69,7 @@ config X86_POWERNOW_K6
 >  config X86_POWERNOW_K7
 >  	tristate "AMD Mobile Athlon/Duron PowerNow!"
 >  	select CPU_FREQ_TABLE
 > -	depends on X86_32
 > +	depends on X86_32 && CPU_FREQ
 >  	help
 >  	  This adds the CPUFreq driver for mobile AMD K7 mobile processors.
 >  
 > @@ -87,7 +87,7 @@ config X86_POWERNOW_K7_ACPI
 >  config X86_POWERNOW_K8
 >  	tristate "AMD Opteron/Athlon64 PowerNow!"
 >  	select CPU_FREQ_TABLE
 > -	depends on ACPI && ACPI_PROCESSOR
 > +	depends on ACPI && ACPI_PROCESSOR && CPU_FREQ
 >  	help
 >  	  This adds the CPUFreq driver for K8/K10 Opteron/Athlon64 processors.
 
This doesn't make sense, as this whole file is guarded with

if CPU_FREQ
...
endif

The dependancy has to be true, or you wouldn't ever see these options.

	Dave

Re: [PATCH 2/3] ACPI: do not define acpi_processor_get_bios_limit() in processor.h

[Dave Jones]

On Tue, Nov 17, 2009 at 03:11:25PM -0700, Alex Chiang wrote:
 > If we provide a definition for acpi_processor_get_bios_limit(), we will
 > encounter build errors (multiple definitions of the function) when we
 > do not have CONFIG_CPU_FREQ configured.
 > 
 > We've already changed the modules that depend on this function to only
 > get built when CONFIG_CPU_FREQ is configured, so removing the definition
 > when unconfigured is safe.
 > 
 > Cc: Thomas Renninger <trenn@suse.de>
 > Cc: Len Brown <lenb@kernel.org>
 > Signed-off-by: Alex Chiang <achiang@hp.com>
 > ---
 > 
 >  include/acpi/processor.h |    5 -----
 >  1 files changed, 0 insertions(+), 5 deletions(-)

There's 2-3 other fixes pending for the bios_limit patch.
For now, I've dropped it from cpufreq.next, until Thomas sends
a rediffed version with the compilation problems fixed.

	Dave

Re: [PATCH 3/3] [CPUFREQ] make internal cpufreq_add_dev_* static

[Dave Jones]

On Tue, Nov 17, 2009 at 03:11:30PM -0700, Alex Chiang wrote:
 > No need to export these symbols; make them static.
 > 
 > 	cpufreq_add_dev_policy
 > 	cpufreq_add_dev_symlink
 > 	cpufreq_add_dev_interface
 > 
 > Signed-off-by: Alex Chiang <achiang@hp.com>
 
Ok. But can you move the parameters to the next line, so that
checkpatch doesn't whine ?

thanks.

	Dave

[PATCH v2] [CPUFREQ] make internal cpufreq_add_dev_* static

[Alex Chiang]

No need to export these symbols; make them static.

	cpufreq_add_dev_policy
	cpufreq_add_dev_symlink
	cpufreq_add_dev_interface

Signed-off-by: Alex Chiang <achiang@hp.com>
---
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 0315069..8c465f1 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -783,8 +783,9 @@ static struct kobj_type ktype_cpufreq = {
  *   0:        Success
  *   Positive: When we have a managed CPU and the sysfs got symlinked
  */
-int cpufreq_add_dev_policy(unsigned int cpu, struct cpufreq_policy *policy,
-		struct sys_device *sys_dev)
+static int cpufreq_add_dev_policy(unsigned int cpu,
+				  struct cpufreq_policy *policy,
+				  struct sys_device *sys_dev)
 {
 	int ret = 0;
 #ifdef CONFIG_SMP
@@ -858,7 +859,8 @@ int cpufreq_add_dev_policy(unsigned int cpu, struct cpufreq_policy *policy,
 
 
 /* symlink affected CPUs */
-int cpufreq_add_dev_symlink(unsigned int cpu, struct cpufreq_policy *policy)
+static int cpufreq_add_dev_symlink(unsigned int cpu,
+				   struct cpufreq_policy *policy)
 {
 	unsigned int j;
 	int ret = 0;
@@ -885,8 +887,9 @@ int cpufreq_add_dev_symlink(unsigned int cpu, struct cpufreq_policy *policy)
 	return ret;
 }
 
-int cpufreq_add_dev_interface(unsigned int cpu, struct cpufreq_policy *policy,
-		struct sys_device *sys_dev)
+static int cpufreq_add_dev_interface(unsigned int cpu,
+				     struct cpufreq_policy *policy,
+				     struct sys_device *sys_dev)
 {
 	struct cpufreq_policy new_policy;
 	struct freq_attr **drv_attr;

Re: [PATCH 1/3] [CPUFREQ] make ACPI P-state cpufreq drivers depend on CONFIG_CPU_FREQ

[Alex Chiang]

* Dave Jones <davej@redhat.com>:
> 
>  > diff --git a/arch/x86/kernel/cpu/cpufreq/Kconfig b/arch/x86/kernel/cpu/cpufreq/Kconfig
>  > index f138c6c..ca40a9f 100644
>  > --- a/arch/x86/kernel/cpu/cpufreq/Kconfig
>  > +++ b/arch/x86/kernel/cpu/cpufreq/Kconfig
>  > @@ -13,7 +13,7 @@ comment "CPUFreq processor drivers"
>  >  config X86_ACPI_CPUFREQ
>  >  	tristate "ACPI Processor P-States driver"
>  >  	select CPU_FREQ_TABLE
>  > -	depends on ACPI_PROCESSOR
>  > +	depends on ACPI_PROCESSOR && CPU_FREQ
>  >  	help
>  >  	  This driver adds a CPUFreq driver which utilizes the ACPI
>  >  	  Processor Performance States.
>  > @@ -69,7 +69,7 @@ config X86_POWERNOW_K6
>  >  config X86_POWERNOW_K7
>  >  	tristate "AMD Mobile Athlon/Duron PowerNow!"
>  >  	select CPU_FREQ_TABLE
>  > -	depends on X86_32
>  > +	depends on X86_32 && CPU_FREQ
>  >  	help
>  >  	  This adds the CPUFreq driver for mobile AMD K7 mobile processors.
>  >  
>  > @@ -87,7 +87,7 @@ config X86_POWERNOW_K7_ACPI
>  >  config X86_POWERNOW_K8
>  >  	tristate "AMD Opteron/Athlon64 PowerNow!"
>  >  	select CPU_FREQ_TABLE
>  > -	depends on ACPI && ACPI_PROCESSOR
>  > +	depends on ACPI && ACPI_PROCESSOR && CPU_FREQ
>  >  	help
>  >  	  This adds the CPUFreq driver for K8/K10 Opteron/Athlon64 processors.
>  
> This doesn't make sense, as this whole file is guarded with
> 
> if CPU_FREQ
> ...
> endif
> 
> The dependancy has to be true, or you wouldn't ever see these options.

Yes, sorry, you're right. Apologies for the noise.

/ac

[PATCH] ACPI: do not define acpi_processor_get_bios_limit() in processor.h (snd ver)

[Thomas Renninger]

Hi,

On Wednesday 18 November 2009 01:09:09 Dave Jones wrote:
> On Tue, Nov 17, 2009 at 03:11:25PM -0700, Alex Chiang wrote:
>  > If we provide a definition for acpi_processor_get_bios_limit(), we will
>  > encounter build errors (multiple definitions of the function) when we
>  > do not have CONFIG_CPU_FREQ configured.
>  > 
>  > We've already changed the modules that depend on this function to only
>  > get built when CONFIG_CPU_FREQ is configured, so removing the definition
>  > when unconfigured is safe.
>  > 
>  > Cc: Thomas Renninger <trenn@suse.de>
>  > Cc: Len Brown <lenb@kernel.org>
>  > Signed-off-by: Alex Chiang <achiang@hp.com>
>  > ---
>  > 
>  >  include/acpi/processor.h |    5 -----
>  >  1 files changed, 0 insertions(+), 5 deletions(-)
> 
> There's 2-3 other fixes pending for the bios_limit patch.
Alex removed the function that should have get
static inline and that looks like the right fix for two
mentioned problems.

> For now, I've dropped it from cpufreq.next, until Thomas sends
> a rediffed version with the compilation problems fixed.
Attached is my old version, merged with Alex's one.
Alex drops out as author of the fix by that, hope that's ok
with you.

I also added a build fix for powernow-k7 if:
# CONFIG_X86_POWERNOW_K7_ACPI is not set

Instead of always including acpi_processor.h, I added:
+#ifdef CONFIG_X86_POWERNOW_K7_ACPI
+       .bios_limit     = acpi_processor_get_bios_limit,
+#endif

Otherwise I could imagine you run into the next trouble if
you enable powernow-k7 (without acpi support) and remove
the acpi processor driver.

I test compiled the relevant cpufreq drivers on i386 with
cpufreq on/off and with CONFIG_X86_POWERNOW_K7_ACPI switched off.

I hope that was all?

Thanks,

    Thomas
---

ACPI/CPUFREQ: Introduce bios_limit per cpu cpufreq sysfs interface

This interface is mainly intended (and implemented) for ACPI _PPC BIOS
frequency limitations, but other cpufreq drivers can also use it for
similar use-cases.

Why is this needed:

Currently it's not obvious why cpufreq got limited.
People see cpufreq/scaling_max_freq reduced, but this could have
happened by:
  - any userspace prog writing to scaling_max_freq
  - thermal limitations
  - hardware (_PPC in ACPI case) limitiations

Therefore export bios_limit (in kHz) to:
  - Point the user that it's the BIOS (broken or intended) which limits
    frequency
  - Export it as a sysfs interface for userspace progs.
    While this was a rarely used feature on laptops, there will appear
    more and more server implemenations providing "Green IT" features like
    allowing the service processor to limit the frequency. People want
    to know about HW/BIOS frequency limitations.

All ACPI P-state driven cpufreq drivers are covered with this patch:
  - powernow-k8
  - powernow-k7
  - acpi-cpufreq

Tested with a patched DSDT which limits the first two cores (_PPC returns 1)
via _PPC, exposed by bios_limit:
# echo 2200000 >cpu2/cpufreq/scaling_max_freq
# cat cpu*/cpufreq/scaling_max_freq
2600000
2600000
2200000
2200000
# #scaling_max_freq shows general user/thermal/BIOS limitations

# cat cpu*/cpufreq/bios_limit
2600000
2600000
2800000
2800000
# #bios_limit only shows the HW/BIOS limitation

CC: Pallipadi Venkatesh <venkatesh.pallipadi@intel.com>
CC: Len Brown <lenb@kernel.org>
CC: davej@codemonkey.org.uk
CC: linux@dominikbrodowski.net

Signed-off-by: Thomas Renninger <trenn@suse.de>

diff --git a/Documentation/cpu-freq/user-guide.txt b/Documentation/cpu-freq/user-guide.txt
index 2a5b850..eeb958b 100644
--- a/Documentation/cpu-freq/user-guide.txt
+++ b/Documentation/cpu-freq/user-guide.txt
@@ -203,6 +203,17 @@ scaling_cur_freq :		Current frequency of the CPU as determined by
 				the frequency the kernel thinks the CPU runs
 				at.
 
+bios_limit :			If the BIOS tells the OS to limit a CPU to
+				lower frequencies, the user can read out the
+				maximum available frequency from this file.
+				This typically can happen through (often not
+				intended) BIOS settings, restrictions
+				triggered through a service processor or other
+				BIOS/HW based implementations.
+				This does not cover thermal ACPI limitations
+				which can be detected through the generic
+				thermal driver.
+				
 If you have selected the "userspace" governor which allows you to
 set the CPU operating frequency to a specific value, you can read out
 the current frequency in
diff --git a/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c b/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
index 8b581d3..d2e7c77 100644
--- a/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
+++ b/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
@@ -764,14 +764,15 @@ static struct freq_attr *acpi_cpufreq_attr[] = {
 };
 
 static struct cpufreq_driver acpi_cpufreq_driver = {
-	.verify = acpi_cpufreq_verify,
-	.target = acpi_cpufreq_target,
-	.init = acpi_cpufreq_cpu_init,
-	.exit = acpi_cpufreq_cpu_exit,
-	.resume = acpi_cpufreq_resume,
-	.name = "acpi-cpufreq",
-	.owner = THIS_MODULE,
-	.attr = acpi_cpufreq_attr,
+	.verify		= acpi_cpufreq_verify,
+	.target		= acpi_cpufreq_target,
+	.bios_limit	= acpi_processor_get_bios_limit,
+	.init		= acpi_cpufreq_cpu_init,
+	.exit		= acpi_cpufreq_cpu_exit,
+	.resume		= acpi_cpufreq_resume,
+	.name		= "acpi-cpufreq",
+	.owner		= THIS_MODULE,
+	.attr		= acpi_cpufreq_attr,
 };
 
 static int __init acpi_cpufreq_init(void)
diff --git a/arch/x86/kernel/cpu/cpufreq/powernow-k7.c b/arch/x86/kernel/cpu/cpufreq/powernow-k7.c
index d47c775..9a97116 100644
--- a/arch/x86/kernel/cpu/cpufreq/powernow-k7.c
+++ b/arch/x86/kernel/cpu/cpufreq/powernow-k7.c
@@ -714,14 +714,17 @@ static struct freq_attr *powernow_table_attr[] = {
 };
 
 static struct cpufreq_driver powernow_driver = {
-	.verify	= powernow_verify,
-	.target	= powernow_target,
-	.get	= powernow_get,
-	.init	= powernow_cpu_init,
-	.exit	= powernow_cpu_exit,
-	.name	= "powernow-k7",
-	.owner	= THIS_MODULE,
-	.attr	= powernow_table_attr,
+	.verify		= powernow_verify,
+	.target		= powernow_target,
+	.get		= powernow_get,
+#ifdef CONFIG_X86_POWERNOW_K7_ACPI
+	.bios_limit	= acpi_processor_get_bios_limit,
+#endif
+	.init		= powernow_cpu_init,
+	.exit		= powernow_cpu_exit,
+	.name		= "powernow-k7",
+	.owner		= THIS_MODULE,
+	.attr		= powernow_table_attr,
 };
 
 static int __init powernow_init(void)
diff --git a/arch/x86/kernel/cpu/cpufreq/powernow-k8.c b/arch/x86/kernel/cpu/cpufreq/powernow-k8.c
index f30d253..a9df944 100644
--- a/arch/x86/kernel/cpu/cpufreq/powernow-k8.c
+++ b/arch/x86/kernel/cpu/cpufreq/powernow-k8.c
@@ -1398,14 +1398,15 @@ static struct freq_attr *powernow_k8_attr[] = {
 };
 
 static struct cpufreq_driver cpufreq_amd64_driver = {
-	.verify = powernowk8_verify,
-	.target = powernowk8_target,
-	.init = powernowk8_cpu_init,
-	.exit = __devexit_p(powernowk8_cpu_exit),
-	.get = powernowk8_get,
-	.name = "powernow-k8",
-	.owner = THIS_MODULE,
-	.attr = powernow_k8_attr,
+	.verify		= powernowk8_verify,
+	.target		= powernowk8_target,
+	.bios_limit	= acpi_processor_get_bios_limit,
+	.init		= powernowk8_cpu_init,
+	.exit		= __devexit_p(powernowk8_cpu_exit),
+	.get		= powernowk8_get,
+	.name		= "powernow-k8",
+	.owner		= THIS_MODULE,
+	.attr		= powernow_k8_attr,
 };
 
 /* driver entry point for init */
diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
index 8ba0ed0..6b4be59 100644
--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi/processor_perflib.c
@@ -167,6 +167,19 @@ int acpi_processor_ppc_has_changed(struct acpi_processor *pr)
 		return cpufreq_update_policy(pr->id);
 }
 
+int acpi_processor_get_bios_limit(int cpu, unsigned int *limit)
+{
+	struct acpi_processor *pr;
+	
+	pr = per_cpu(processors, cpu);
+	if (!pr || !pr->performance || !pr->performance->state_count)
+		return -ENODEV;
+	*limit = pr->performance->states[pr->performance_platform_limit].
+		core_frequency * 1000;
+	return 0;
+}
+EXPORT_SYMBOL(acpi_processor_get_bios_limit);
+
 void acpi_processor_ppc_init(void)
 {
 	if (!cpufreq_register_notifier
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 5b9b1c8..f20668c 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -647,6 +647,21 @@ static ssize_t show_scaling_setspeed(struct cpufreq_policy *policy, char *buf)
 	return policy->governor->show_setspeed(policy, buf);
 }
 
+/**
+ * show_scaling_driver - show the current cpufreq HW/BIOS limitation
+ */
+static ssize_t show_bios_limit(struct cpufreq_policy *policy, char *buf)
+{
+	unsigned int limit;
+	int ret;
+	if (cpufreq_driver->bios_limit) {
+		ret = cpufreq_driver->bios_limit(policy->cpu, &limit);
+		if (!ret)
+			return sprintf(buf, "%u\n", limit);
+	}
+	return sprintf(buf, "%u\n", policy->cpuinfo.max_freq);
+}
+
 #define define_one_ro(_name) \
 static struct freq_attr _name = \
 __ATTR(_name, 0444, show_##_name, NULL)
@@ -666,6 +681,7 @@ define_one_ro(cpuinfo_transition_latency);
 define_one_ro(scaling_available_governors);
 define_one_ro(scaling_driver);
 define_one_ro(scaling_cur_freq);
+define_one_ro(bios_limit);
 define_one_ro(related_cpus);
 define_one_ro(affected_cpus);
 define_one_rw(scaling_min_freq);
@@ -905,6 +921,11 @@ static int cpufreq_add_dev_interface(unsigned int cpu,
 		if (ret)
 			goto err_out_kobj_put;
 	}
+	if (cpufreq_driver->bios_limit) {
+		ret = sysfs_create_file(&policy->kobj, &bios_limit.attr);
+		if (ret)
+			goto err_out_kobj_put;
+	}
 
 	spin_lock_irqsave(&cpufreq_driver_lock, flags);
 	for_each_cpu(j, policy->cpus) {
diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index 740ac3a..8b668ea 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -295,6 +295,7 @@ static inline void acpi_processor_ffh_cstate_enter(struct acpi_processor_cx
 void acpi_processor_ppc_init(void);
 void acpi_processor_ppc_exit(void);
 int acpi_processor_ppc_has_changed(struct acpi_processor *pr);
+extern int acpi_processor_get_bios_limit(int cpu, unsigned int *limit);
 #else
 static inline void acpi_processor_ppc_init(void)
 {
@@ -316,6 +317,11 @@ static inline int acpi_processor_ppc_has_changed(struct acpi_processor *pr)
 	}
 	return 0;
 }
+static inline int acpi_processor_get_bios_limit(int cpu, unsigned int *limit)
+{
+	return -ENODEV;
+}
+
 #endif				/* CONFIG_CPU_FREQ */
 
 /* in processor_throttling.c */
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 79a2340..4de02b1 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -232,6 +232,7 @@ struct cpufreq_driver {
 	/* optional */
 	unsigned int (*getavg)	(struct cpufreq_policy *policy,
 				 unsigned int cpu);
+	int	(*bios_limit)	(int cpu, unsigned int *limit);
 
 	int	(*exit)		(struct cpufreq_policy *policy);
 	int	(*suspend)	(struct cpufreq_policy *policy, pm_message_t pmsg);

Re: [PATCH] ACPI: do not define acpi_processor_get_bios_limit() in processor.h (snd ver)

[Alex Chiang]

* Thomas Renninger <trenn@suse.de>:
> > 
> > There's 2-3 other fixes pending for the bios_limit patch.
> Alex removed the function that should have get
> static inline and that looks like the right fix for two
> mentioned problems.
> 
> > For now, I've dropped it from cpufreq.next, until Thomas sends
> > a rediffed version with the compilation problems fixed.
> Attached is my old version, merged with Alex's one.
> Alex drops out as author of the fix by that, hope that's ok
> with you.

That's fine, maybe do what akpm does...

[achiang@hp.com fix build breakage]
> CC: Pallipadi Venkatesh <venkatesh.pallipadi@intel.com>
> CC: Len Brown <lenb@kernel.org>
> CC: davej@codemonkey.org.uk
> CC: linux@dominikbrodowski.net
> 
> Signed-off-by: Thomas Renninger <trenn@suse.de>

But either way is fine by me.

/ac