| Message ID | adaskecyqrw.fsf@cisco.com (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers | show |
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c index c2d4d6e..c567b46 100644 --- a/drivers/acpi/processor_core.c +++ b/drivers/acpi/processor_core.c @@ -863,13 +863,6 @@ static int acpi_processor_add(struct acpi_device *device) goto err_remove_sysfs; } - if (pr->flags.throttling) { - printk(KERN_INFO PREFIX "%s [%s] (supports", - acpi_device_name(device), acpi_device_bid(device)); - printk(" %d throttling states", pr->throttling.state_count); - printk(")\n"); - } - return 0; err_remove_sysfs:
I was recently lucky enough to get a 64-CPU system. The processors actually have T-states, so my kernel log ends up with 64 lines like: ACPI: Processor [CPU0] (supports xx throttling states) This is pretty useless clutter because - this info is already available after boot from /proc/acpi/processor/CPUnn/throttling - there's also an ACPI_DEBUG_PRINT() in processor_throttling.c that gives the same info on boot for anyone who *really* cares. So just delete the code that prints the throttling states in processor_core.c. Signed-off-by: Roland Dreier <rolandd@cisco.com> --- drivers/acpi/processor_core.c | 7 ------- 1 files changed, 0 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html