Re: [PATCH RFC 2/5] ACPI / processor: always compile perflib if CONFIG_ACPI_PROCESSOR

From: Hanjun Guo
Date: Fri May 08 2015 - 04:53:57 EST


On 2015å05æ07æ 02:36, Ashwin Chaugule wrote:
Hello,

On 6 May 2015 at 10:31, Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
Similar to the idle, thermal and throttling libraries, always compile
the perflib if CONFIG_ACPI_PROCESSOR is enabled. This not only makes
perflib alligned with other libraries but also helps in some sanity
testing of these ACPI methods even when a particular feature is not
enabled in the kernel configuration.

Signed-off-by: Sudeep Holla <sudeep.holla@xxxxxxx>
---
drivers/acpi/Makefile | 2 +-
include/acpi/processor.h | 29 -----------------------------
include/linux/cpufreq.h | 4 ++++
3 files changed, 5 insertions(+), 30 deletions(-)

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 8a063e276530..33aef9d8b260 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -84,7 +84,7 @@ obj-$(CONFIG_ACPI_BGRT) += bgrt.o
# processor has its own "processor." module_param namespace
processor-y := processor_driver.o processor_throttling.o
processor-y += processor_idle.o processor_thermal.o
-processor-$(CONFIG_CPU_FREQ) += processor_perflib.o
+processor-y += processor_perflib.o

I'd prefer that we create a separate kconfig option for this. (perhaps
even default it to 'y'). This library is quite specific to a certain
type of CPU performance management methods (includes _PSS and friends)
which are superseded by CPPC. The OS is not expected to support both
at runtime, so by keeping this a config option, we can then disable it
at compile time when CPPC is enabled. We could couple

I agree. CPPC and _PSS are different way of controlling CPU freq,
and I think _PSS may not be used on ARM.

Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/