linux-stable.git/drivers/acpi/processor_core.c, branch linux-2.6.32.y Linux kernel stable tree ACPI: delete ZEPTO idle=nomwait DMI quirk 2010-10-29T04:44:15+00:00 Len Brown len.brown@intel.com 2010-09-28T21:20:20+00:00 47de918e751ae19c78d923b92566072d70f9f3ae commit 64a32307b710c100beb101e9c78f8022f0e8ba61 upstream. per comments in the bug report, this entry seems to hurt at much as it helps. https://bugzilla.kernel.org/show_bug.cgi?id=10807 Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 64a32307b710c100beb101e9c78f8022f0e8ba61 upstream.

per comments in the bug report, this entry
seems to hurt at much as it helps.

https://bugzilla.kernel.org/show_bug.cgi?id=10807

Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ACPI: add __cpuinit to acpi_processor_add() 2009-11-05T21:51:40+00:00 Rakib Mullick rakib.mullick@gmail.com 2009-11-05T21:51:40+00:00 941b10fab2cbd90ac7ad6bc2338ffe30e1d3ce53 Annote acpi_processor_add with cpuinit since it calls a cpuinit function acpi_processor_power_init and fixes a section mismatch warning. We were warned by the following warning: LD drivers/acpi/processor.o WARNING: drivers/acpi/processor.o(.text+0x1829): Section mismatch in reference from the function acpi_processor_add() to the function .cpuinit.text:acpi_processor_power_init() The function acpi_processor_add() references the function __cpuinit acpi_processor_power_init(). This is often because acpi_processor_add lacks a __cpuinit annotation or the annotation of acpi_processor_power_init is wrong. Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com> 
Annote acpi_processor_add with cpuinit since it calls a cpuinit function
acpi_processor_power_init and fixes a section mismatch warning.

 We were warned by the following warning:

 LD      drivers/acpi/processor.o
WARNING: drivers/acpi/processor.o(.text+0x1829): Section mismatch in
reference from the function acpi_processor_add() to the function
.cpuinit.text:acpi_processor_power_init()
The function acpi_processor_add() references
the function __cpuinit acpi_processor_power_init().
This is often because acpi_processor_add lacks a __cpuinit
annotation or the annotation of acpi_processor_power_init is wrong.

Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
ACPI: kill overly verbose "throttling states" log messages 2009-10-03T05:06:12+00:00 Roland Dreier rdreier@cisco.com 2009-09-30T20:58:03+00:00 53412c5b1225db77f7ac04b6a5351e60ea2a280f 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> 
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>
Merge branch 'processor-procfs-2.6.32' into release 2009-09-19T06:10:40+00:00 Len Brown len.brown@intel.com 2009-09-19T06:10:40+00:00 cbeee13570adfb0af494a07074958e4888c2351c 






Merge branch 'bjorn-start-stop-2.6.32' into release
2009-09-19T05:56:39+00:00

Len Brown
len.brown@intel.com

2009-09-19T05:56:39+00:00

3b87bb640e77023c97cf209e3dd85887a1113ad0












ACPI: Move definition of PREFIX from acpi_bus.h to internal..h
2009-08-28T23:57:27+00:00

Len Brown
len.brown@intel.com

2009-07-28T20:45:54+00:00

a192a9580bcc41692be1f36b77c3b681827f566a

Linux/ACPI core files using internal.h all PREFIX "ACPI: ",
however, not all ACPI drivers use/want it -- and they
should not have to #undef PREFIX to define their own.

Add GPL commment to internal.h while we are there.

This does not change any actual console output,
asside from a whitespace fix.

Signed-off-by: Len Brown <len.brown@intel.com>





Linux/ACPI core files using internal.h all PREFIX "ACPI: ",
however, not all ACPI drivers use/want it -- and they
should not have to #undef PREFIX to define their own.

Add GPL commment to internal.h while we are there.

This does not change any actual console output,
asside from a whitespace fix.

Signed-off-by: Len Brown <len.brown@intel.com>







acpi: don't call acpi_processor_init if acpi is disabled
2009-08-27T03:06:52+00:00

Yinghai Lu
yinghai@kernel.org

2009-08-26T21:29:26+00:00

ce8442b55135c679809311997d1446f3bbc05de2

Jens reported early_ioremap messages with old ASUS board...

> [    1.507461] pci 0000:00:09.0: Firmware left e100 interrupts enabled; disabling
> [    1.532778] early_ioremap(3fffd080, 0000005c) [0] => Pid: 1, comm: swapper Not tainted 2.6.31-rc4 #36
> [    1.561007] Call Trace:
> [    1.568638]  [<c136e48b>] ? printk+0x18/0x1d
> [    1.581734]  [<c15513ff>] __early_ioremap+0x74/0x1e9
> [    1.596898]  [<c15515aa>] early_ioremap+0x1a/0x1c
> [    1.611270]  [<c154a187>] __acpi_map_table+0x18/0x1a
> [    1.626451]  [<c135a7f8>] acpi_os_map_memory+0x1d/0x25
> [    1.642129]  [<c119459c>] acpi_tb_verify_table+0x20/0x49
> [    1.658321]  [<c1193e50>] acpi_get_table_with_size+0x53/0xa1
> [    1.675553]  [<c1193eae>] acpi_get_table+0x10/0x15
> [    1.690192]  [<c155cc19>] acpi_processor_init+0x23/0xab
> [    1.706126]  [<c1001043>] do_one_initcall+0x33/0x180
> [    1.721279]  [<c155cbf6>] ? acpi_processor_init+0x0/0xab
> [    1.737479]  [<c106893a>] ? register_irq_proc+0xaa/0xc0
> [    1.753411]  [<c10689b7>] ? init_irq_proc+0x67/0x80
> [    1.768316]  [<c15405e7>] kernel_init+0x120/0x176
> [    1.782678]  [<c15404c7>] ? kernel_init+0x0/0x176
> [    1.797062]  [<c10038b7>] kernel_thread_helper+0x7/0x10
> [    1.812984] 00000080 + ffe00000

that is rather later.
acpi_gbl_permanent_mmap should be set in acpi_early_init()
if acpi is not disabled

and we have
> [    0.000000] ASUS P2B-DS detected: force use of acpi=ht

just don't load acpi_processor_init...

Reported-and-tested-by: Jens Rosenboom <jens@leia.mcbone.net>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Ingo Molnar <mingo@elte.hu>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>





Jens reported early_ioremap messages with old ASUS board...

> [    1.507461] pci 0000:00:09.0: Firmware left e100 interrupts enabled; disabling
> [    1.532778] early_ioremap(3fffd080, 0000005c) [0] => Pid: 1, comm: swapper Not tainted 2.6.31-rc4 #36
> [    1.561007] Call Trace:
> [    1.568638]  [<c136e48b>] ? printk+0x18/0x1d
> [    1.581734]  [<c15513ff>] __early_ioremap+0x74/0x1e9
> [    1.596898]  [<c15515aa>] early_ioremap+0x1a/0x1c
> [    1.611270]  [<c154a187>] __acpi_map_table+0x18/0x1a
> [    1.626451]  [<c135a7f8>] acpi_os_map_memory+0x1d/0x25
> [    1.642129]  [<c119459c>] acpi_tb_verify_table+0x20/0x49
> [    1.658321]  [<c1193e50>] acpi_get_table_with_size+0x53/0xa1
> [    1.675553]  [<c1193eae>] acpi_get_table+0x10/0x15
> [    1.690192]  [<c155cc19>] acpi_processor_init+0x23/0xab
> [    1.706126]  [<c1001043>] do_one_initcall+0x33/0x180
> [    1.721279]  [<c155cbf6>] ? acpi_processor_init+0x0/0xab
> [    1.737479]  [<c106893a>] ? register_irq_proc+0xaa/0xc0
> [    1.753411]  [<c10689b7>] ? init_irq_proc+0x67/0x80
> [    1.768316]  [<c15405e7>] kernel_init+0x120/0x176
> [    1.782678]  [<c15404c7>] ? kernel_init+0x0/0x176
> [    1.797062]  [<c10038b7>] kernel_thread_helper+0x7/0x10
> [    1.812984] 00000080 + ffe00000

that is rather later.
acpi_gbl_permanent_mmap should be set in acpi_early_init()
if acpi is not disabled

and we have
> [    0.000000] ASUS P2B-DS detected: force use of acpi=ht

just don't load acpi_processor_init...

Reported-and-tested-by: Jens Rosenboom <jens@leia.mcbone.net>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Ingo Molnar <mingo@elte.hu>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>







ACPI: processor: remove .start() method
2009-06-25T16:16:33+00:00

Bjorn Helgaas
bjorn.helgaas@hp.com

2009-06-22T20:41:19+00:00

970b04929a68134acca17878b1d93e115e58c12a

This patch folds the .start() method into .add().

acpi_processor_start() is always called immediately after
acpi_processor_add(), so there's really no point in having them be
separate methods.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Reviewed-by: Alex Chiang <achiang@hp.com>
CC: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
CC: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>





This patch folds the .start() method into .add().

acpi_processor_start() is always called immediately after
acpi_processor_add(), so there's really no point in having them be
separate methods.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Reviewed-by: Alex Chiang <achiang@hp.com>
CC: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
CC: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>







ACPI: processor: move acpi_processor_start() after acpi_processor_add()
2009-06-25T16:16:32+00:00

Bjorn Helgaas
bjorn.helgaas@hp.com

2009-06-22T20:41:14+00:00

ddcd62d89e8c919cc75aeffd2ca37c986141b0f0

Move acpi_processor_start() to just after acpi_processor_add().
A subsequent patch will merge them.

Code movement only; no functional change.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
CC: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>





Move acpi_processor_start() to just after acpi_processor_add().
A subsequent patch will merge them.

Code movement only; no functional change.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
CC: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>







ACPI: processor: clean up in acpi_processor_start() error exits
2009-06-25T16:16:32+00:00

Bjorn Helgaas
bjorn.helgaas@hp.com

2009-06-22T20:41:09+00:00

d4e0526184199e23ac1460fe59b8a3741b17a8b5

We used to leave crud around if things failed in acpi_processor_start().
This patch cleans up as much as we can before returning.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Reviewed-by: Alex Chiang <achiang@hp.com>
CC: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
CC: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>





We used to leave crud around if things failed in acpi_processor_start().
This patch cleans up as much as we can before returning.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Reviewed-by: Alex Chiang <achiang@hp.com>
CC: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
CC: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>