linux-toradex.git/drivers/acpi, branch v2.6.31.10

Revert "ACPI: Attach the ACPI device to the ACPI handle as early as possible"

2009-11-10T00:22:49+00:00

commit f61f925859c57f6175082aeeee17743c68558a6e upstream.

This reverts commit eab4b645769fa2f8703f5a3cb0cc4ac090d347af.

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

Signed-off-by: Len Brown 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

ACPI / PCI: Fix NULL pointer dereference in acpi_get_pci_dev() (rev. 2)

2009-11-10T00:22:48+00:00

commit 497fb54f578efd2b479727bc88d5ef942c0a1e2d upstream.

acpi_get_pci_dev() may be called for a non-PCI device, in which case
it should return NULL.  However, it assumes that every handle it
finds in the ACPI CA name space, between given device handle and the
PCI root bridge handle, corresponds to a PCI-to-PCI bridge with an
existing secondary bus.  For this reason, when it finds a struct
pci_dev object corresponding to one of them, it doesn't check if
its 'subordinate' field is a valid pointer.  This obviously leads to
a NULL pointer dereference if acpi_get_pci_dev() is called for a
non-PCI device with a PCI parent which is not a bridge.

To fix this issue make acpi_get_pci_dev() check if pdev->subordinate
is not NULL for every device it finds on the path between the root
bridge and the device it's supposed to get to and return NULL if the
"target" device cannot be found.

http://bugzilla.kernel.org/show_bug.cgi?id=14129
(worked in 2.6.30, regression in 2.6.31)

Signed-off-by: Rafael J. Wysocki 
Reported-by: Danny Feng 
Reviewed-by: Alex Chiang 
Tested-by: chepioq 
Signed-off-by: Len Brown 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

ACPI: Clarify resource conflict message

2009-10-12T19:40:22+00:00

commit 14f03343ad1080c2fea29ab2c13f05b976c4584e upstream.

The message "ACPI: Device needs an ACPI driver" is misleading. The
device _may_ need an ACPI driver, if the BIOS implemented a custom
API for the device in question (which, AFAIK, can't be checked.) If
not, then either a generic ACPI driver may be used (for example
"thermal"), or nothing can be done (other than a white list).

I propose to reword the message to:

ACPI: If an ACPI driver is available for this device, you should use
it instead of the native driver

which I think is more correct. Comments and suggestions welcome.

I also added a message warning about possible problems and system
instability when users pass acpi_enforce_resources=lax, as suggested
by Len.

Signed-off-by: Jean Delvare 
Cc: Thomas Renninger 
Cc: Alan Jenkins 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

ACPI: pci_slot.ko wants a 64-bit _SUN

2009-10-05T16:31:35+00:00

commit 7e24bc1ce669b2876ffa475ea1147f2bb9ffdc52 upstream.

Similar to commit b6adc195 (PCI hotplug: acpiphp wants a 64-bit
_SUN), pci_slot.ko reads and creates sysfs directories based on
the _SUN method.

Certain HP platforms return 64 bits in _SUN. This change to
pci_slot.ko allows us to see the correct sysfs directories.

Reported-by: Chad Smith 
Signed-off-by: Alex Chiang 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

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