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

Merge branch 'pcc' into release

2010-02-23T05:39:00+00:00

ACPI: Be in TS_POLLING state during mwait based C-state entry

2010-02-22T18:10:14+00:00

ACPI deep C-state entry had a long standing bug/missing feature, wherein we were sending
resched IPIs when an idle CPU is in mwait based deep C-state. Only mwait based C1 was using
the write to the monitored address to wake up mwait'ing CPU.

This patch changes the code to retain TS_POLLING bit if we are entering an mwait based
deep C-state.

The patch has been verified to reduce the number of resched IPIs in general and also
improves the performance/power on workloads with low system utilization (i.e., when mwait based
deep C-states are being used).

Fixes "netperf ~50% regression with 2.6.33-rc1, bisect to 1b9508f"
http://marc.info/?l=linux-kernel&m=126441481427331&w=4

Reported-by: Lin Ming 
Tested-by: Alex Shi 
Signed-off-by: Venkatesh Pallipadi 
Signed-off-by: Len Brown

ACPI: Fix regression where _PPC is not read at boot even when ignore_ppc=0

2010-02-19T06:11:48+00:00

Earlier, Ingo Molnar posted a patch to make it so that the kernel would avoid
reading _PPC on his broken T60.  Unfortunately, it seems that with Thomas
Renninger's patch last July to eliminate _PPC evaluations when the processor
driver loads, the kernel never actually reads _PPC at all!  This is problematic
if you happen to boot your non-T60 computer in a state where the BIOS _wants_
_PPC to be something other than zero.

So, put the _PPC evaluation back into acpi_processor_get_performance_info if
ignore_ppc isn't 1.

Signed-off-by: Darrick J. Wong 
Signed-off-by: Len Brown

Merge branches 'bugzilla-14886', 'bugzilla-15000', 'bugzilla-15040', 'bugzilla-15108', 'pdc', 'hotplug-null-ref' and 'thinkpad' into release

2010-02-18T08:51:04+00:00

ACPI: fix "acpi=ht" boot option

2010-02-18T08:49:38+00:00

We broke "acpi=ht" in 2.6.32 by disabling MADT parsing
for acpi=disabled.  e5b8fc6ac158f65598f58dba2c0d52ba3b412f52
This also broke systems which invoked acpi=ht via DMI blacklist.

acpi=ht is a really ugly hack,
but restore it for those that still use it.

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

Signed-off-by: Len Brown

ACPI: fix High cpu temperature with 2.6.32

2010-02-16T09:11:27+00:00

Since the rewrite of the CPU idle governor in 2.6.32, two laptops have
surfaced where the BIOS advertises a C2 power state, but for some reason
this state is not functioning (as verified in both cases by powertop
before the patch in .32).

The old governor had the accidental behavior that if a non-working state
was chosen too many times, it would end up falling back to C1.  The new
governor works differently and this accidental behavior is no longer
there; the result is a high temperature on these two machines.

This patch adds these 2 machines to the DMI table for C state anomalies;
by just not using C2 both these machines are better off (the TSC can be
used instead of the pm timer, giving a performance boost for example).

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

Signed-off-by: Arjan van de Ven 
Reported-by: 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Len Brown

ACPI: dock: properly initialize local struct dock_station in dock_add()

2010-02-16T08:54:28+00:00

Commit fe06fba2 (ACPI: dock: add struct dock_station * directly
to platform device data) changed dock_add() to use the
platform_device_register_data() API.

We passed that interface a stack variable, which is kmemdup'ed
and assigned to the device's platform_data pointer.

Unfortunately, whatever random garbage is in the stack variable
gets coped during the kmemdup, and that leads to broken behavior.

Explicitly zero out the structure before passing it to the API.

This fixes the T41 docking button issue:
http://bugzilla.kernel.org/show_bug.cgi?id=15000

Cc: stable@kernel.org
Reported-by: Chris Mason 
Signed-off-by: Alex Chiang 
Signed-off-by: Len Brown

ACPI: acpi_bus_{scan,bus,add}: return -ENODEV if no device was found

2010-02-01T02:43:32+00:00

Callers (acpi_memhotplug.c, dock.c and others) check for the return
value of acpi_bus_add() and assume a valid device was returned in
case zero was returned.

Thus return -ENODEV if no device was found in acpi_bus_scan and
propagate this through acpi_bus_add and acpi_bus_start.

Also remove a confusing comment in acpiphp_glue.c, acpi_bus_scan
will and cannot invoke if acpi_bus_add returns no valid device.

Signed-off-by: Thomas Renninger 
Acked-by: Bjorn Helgaas 
Signed-off-by: Len Brown

ACPI: Add NULL pointer check in acpi_bus_start

2010-02-01T02:43:04+00:00

If acpi_bus_add does not return a device and it's passed
to acpi_bus_start, bad things will happen:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
IP: [] acpi_bus_start+0x14/0x24
...
[] acpiphp_bus_add+0xba/0x130 [acpiphp]
[] enable_device+0x132/0x2ff [acpiphp]
[] acpiphp_enable_slot+0xb8/0x130 [acpiphp]
[] handle_hotplug_event_func+0x87/0x190 [acpiphp]

Next patch would make this NULL pointer check obsolete, but
better having one more than one missing...

Signed-off-by: Thomas Renninger 
Acked-by: Bjorn Helgaas 
CC: stable@kernel.org
Signed-off-by: Len Brown

ACPI: processor: only evaluate _PDC once per processor

2010-01-22T17:39:56+00:00

If we evaluate _PDC in the early path, we do not want to evaluate
it again when the processor driver is loaded.

Cc: Venkatesh Pallipadi 
Signed-off-by: Alex Chiang 
Signed-off-by: Len Brown