linux.git/drivers/acpi, branch v2.6.31

ACPI: don't free non-existent backlight in acpi video module

2009-08-28T19:17:07+00:00

acpi_video_put_one_device was attempting to remove sysfs entries and
unregister a backlight device without first checking that said backlight
device structure had been created.

Signed-off-by: Keith Packard 
Acked-by: Zhang Rui 
Signed-off-by: Andrew Morton 
Signed-off-by: Len Brown

ACPICA: Windows compatibility fix: same buffer/string store

2009-08-28T19:17:07+00:00

Fix a compatibility issue when the same buffer or string is
stored to itself. This has been seen in the field. Previously,
ACPICA would zero out the buffer/string. Now, the operation is
treated as a NOP.

http://bugzilla.acpica.org/show_bug.cgi?id=803

Reported-by: Rezwanul Kabir 
Signed-off-by: Lin Ming 
Signed-off-by: Bob Moore 
Signed-off-by: Len Brown

acpi processor: remove superfluous warning message

2009-08-27T03:06:53+00:00

This failure is very common on many platforms.  Handling it in the ACPI
processor driver is enough, and we don't need a warning message unless
CONFIG_ACPI_DEBUG is set.

Based on a patch from Zhang Rui.

Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13389

Signed-off-by: Frans Pop 
Acked-by: Zhang Rui 
Cc: Len Brown 
Cc: "Rafael J. Wysocki" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

ACPI processor: force throttling state when BIOS returns incorrect value

2009-08-27T03:06:53+00:00

If the BIOS reports an invalid throttling state (which seems to be
fairly common after system boot), a reset is done to state T0.
Because of a check in acpi_processor_get_throttling_ptc(), the reset
never actually gets executed, which results in the error reoccurring
on every access of for example /proc/acpi/processor/CPU0/throttling.

Add a 'force' option to acpi_processor_set_throttling() to ensure
the reset really takes effect.

Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13389

This patch, together with the next one, fixes a regression introduced in
2.6.30, listed on the regression list. They have been available for 2.5
months now in bugzilla, but have not been picked up, despite various
reminders and without any reason given.

Google shows that numerous people are hitting this issue. The issue is in
itself relatively minor, but the bug in the code is clear.

The patches have been in all my kernels and today testing has shown that
throttling works correctly with the patches applied when the system
overheats (http://bugzilla.kernel.org/show_bug.cgi?id=13918#c14).

Signed-off-by: Frans Pop 
Acked-by: Zhang Rui 
Cc: Len Brown 
Cc: "Rafael J. Wysocki" 
Cc: Rusty Russell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

acpi: don't call acpi_processor_init if acpi is disabled

2009-08-27T03:06:52+00:00

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]  [] ? printk+0x18/0x1d
> [    1.581734]  [] __early_ioremap+0x74/0x1e9
> [    1.596898]  [] early_ioremap+0x1a/0x1c
> [    1.611270]  [] __acpi_map_table+0x18/0x1a
> [    1.626451]  [] acpi_os_map_memory+0x1d/0x25
> [    1.642129]  [] acpi_tb_verify_table+0x20/0x49
> [    1.658321]  [] acpi_get_table_with_size+0x53/0xa1
> [    1.675553]  [] acpi_get_table+0x10/0x15
> [    1.690192]  [] acpi_processor_init+0x23/0xab
> [    1.706126]  [] do_one_initcall+0x33/0x180
> [    1.721279]  [] ? acpi_processor_init+0x0/0xab
> [    1.737479]  [] ? register_irq_proc+0xaa/0xc0
> [    1.753411]  [] ? init_irq_proc+0x67/0x80
> [    1.768316]  [] kernel_init+0x120/0x176
> [    1.782678]  [] ? kernel_init+0x0/0x176
> [    1.797062]  [] 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 
Signed-off-by: Yinghai Lu 
Acked-by: Ingo Molnar 
Cc: Len Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

clockevent: Prevent dead lock on clockevents_lock

2009-08-19T16:15:10+00:00

Currently clockevents_notify() is called with interrupts enabled at
some places and interrupts disabled at some other places.

This results in a deadlock in this scenario.

cpu A holds clockevents_lock in clockevents_notify() with irqs enabled
cpu B waits for clockevents_lock in clockevents_notify() with irqs disabled
cpu C doing set_mtrr() which will try to rendezvous of all the cpus.

This will result in C and A come to the rendezvous point and waiting
for B. B is stuck forever waiting for the spinlock and thus not
reaching the rendezvous point.

Fix the clockevents code so that clockevents_lock is taken with
interrupts disabled and thus avoid the above deadlock.

Also call lapic_timer_propagate_broadcast() on the destination cpu so
that we avoid calling smp_call_function() in the clockevents notifier
chain.

This issue left us wondering if we need to change the MTRR rendezvous
logic to use stop machine logic (instead of smp_call_function) or add
a check in spinlock debug code to see if there are other spinlocks
which gets taken under both interrupts enabled/disabled conditions.

Signed-off-by: Suresh Siddha 
Signed-off-by: Venkatesh Pallipadi 
Cc: "Pallipadi Venkatesh" 
Cc: "Brown Len" 
LKML-Reference: <1250544899.2709.210.camel@sbs-t61.sc.intel.com>
Signed-off-by: Thomas Gleixner

Merge branch 'misc-2.6.31' into release

2009-08-02T16:55:51+00:00

Merge branch 'memhotplug-crash' into release

2009-08-02T16:27:26+00:00

ACPI: Ingore the memory block with zero block size in course of memory hotplug

2009-08-02T16:25:12+00:00

If the memory block size is zero, ignore it and don't do the memory hotplug
flowchart. Otherwise it will complain the following warning message:
  >System RAM resource 0 - ffffffffffffffff cannot be added

Signed-off-by: Zhao Yakui 
Signed-off-by: Len Brown

ACPI: Don't treat generic error as ACPI error code in acpi memory hotplug driver

2009-08-02T16:24:59+00:00

Don't treat the generic error as ACPI error code. Otherwise when the generic
code is returned, it will complain the following warning messag:
   >ACPI Exception (acpi_memhotplug-0171): UNKNOWN_STATUS_CODE,
		Cannot get acpi bus device [20080609]
   >ACPI: Cannot find driver data
   > ACPI Error (utglobal-0127): Unknown exception code: 0xFFFFFFED [20080609]
   > Pid: 85, comm: kacpi_notify Not tainted 2.6.27.19-5-default #1
     Call Trace:
     [] show_trace_log_lvl+0x41/0x58
     [] dump_stack+0x69/0x6f
    .....

At the same time when the generic error code is returned, the ACPI_EXCEPTION
is replaced by the printk.

Signed-off-by: Zhao Yakui 
Signed-off-by: Len Brown