diff options
| author | Roland Dreier <rdreier@cisco.com> | 2009-09-30 13:58:03 -0700 |
|---|---|---|
| committer | Len Brown <len.brown@intel.com> | 2009-10-03 01:06:12 -0400 |
| commit | 53412c5b1225db77f7ac04b6a5351e60ea2a280f (patch) | |
| tree | 6d4399d7ab5c7fda6f8acc5d9e68f22dc3b6a198 /drivers/acpi/processor_core.c | |
| parent | d9f65018065ee1b161a85f54132193f248a45439 (diff) | |
| download | linux-stable-53412c5b1225db77f7ac04b6a5351e60ea2a280f.tar.gz linux-stable-53412c5b1225db77f7ac04b6a5351e60ea2a280f.tar.bz2 linux-stable-53412c5b1225db77f7ac04b6a5351e60ea2a280f.zip | |
ACPI: kill overly verbose "throttling states" log messages
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>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Diffstat (limited to 'drivers/acpi/processor_core.c')
| -rw-r--r-- | drivers/acpi/processor_core.c | 7 |
1 files changed, 0 insertions, 7 deletions
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c index c2d4d6e09364..c567b46dfa0f 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: |