linux-stable.git/drivers/acpi, branch linux-2.6.25.y

ACPI: video: fix brightness allocation

2008-11-10T18:50:07+00:00

Thanks to Arjan for spotting this for .stable:
http://www.kerneloops.org/search.php?search=acpi_video_switch_brightness

upstream commit 469778c1740fcf3113498b6fdf4559bdec25c58f

ACPI: video: fix brightness allocation

Fix use of uninitialized device->brightness.

Signed-off-by: Julia Jomantaite 
Signed-off-by: Andi Kleen 
Acked-by: Zhang Rui 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

ACPI: dock: avoid check _STA method

2008-11-10T18:50:06+00:00

commit 8b59560a3baf2e7c24e0fb92ea5d09eca92805db upstream.

ACPI: dock: avoid check _STA method

In some BIOSes, every _STA method call will send a notification again,
this cause freeze. And in some BIOSes, it appears _STA should be called
after _DCK. This tries to avoid calls _STA, and still keep the device
present check.

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

Signed-off-by: Shaohua Li 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

ACPI: Avoid bogus EC timeout when EC is in Polling mode

2008-10-09T02:44:41+00:00

commit 9d699ed92a459cb408e2577e8bbeabc8ec3989e1 upstream

When EC is in Polling mode, OS will check the EC status continually by using
the following source code:
       clear_bit(EC_FLAGS_WAIT_GPE, &ec->flags);
       while (time_before(jiffies, delay)) {
               if (acpi_ec_check_status(ec, event))
       	            return 0;
               msleep(1);
       }
But msleep is realized by the function of schedule_timeout. At the same time
although one process is already waken up by some events, it won't be scheduled
immediately. So maybe there exists the following phenomena:
     a. The current jiffies is already after the predefined jiffies.
	But before timeout happens, OS has no chance to check the EC
	status again.
     b. If preemptible schedule is enabled, maybe preempt schedule will happen
	before checking loop. When the process is resumed again, maybe
	timeout already happens, which means that OS has no chance to check
	the EC status.

In such case maybe EC status is already what OS expects when timeout happens.
But OS has no chance to check the EC status and regards it as AE_TIME.

So it will be more appropriate that OS will try to check the EC status again
when timeout happens. If the EC status is what we expect, it won't be regarded
as timeout. Only when the EC status is not what we expect, it will be regarded
as timeout, which means that EC controller can't give a response in time.

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

Signed-off-by: Zhao Yakui 
Signed-off-by: Zhang Rui  
Signed-off-by: Andi Kleen 
Signed-off-by: Greg Kroah-Hartman

ACPI: Fix thermal shutdowns

2008-10-09T02:44:40+00:00

commit 9f497bcc695fb828da023d74ad3c966b1e58ad21 upstream

ACPI: Fix thermal shutdowns

Do not use unsigned int if there is test for negative number...

See drivers/acpi/processor_perflib.c
  static unsigned int ignore_ppc = -1;
...
  if (event == CPUFREQ_START && ignore_ppc <= 0) {
       ignore_ppc = 0;
...

Signed-off-by: Milan Broz 
Signed-off-by: Andi Kleen 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

ACPI: update thermal temperature

2008-08-06T17:11:04+00:00

commit 76ecb4f2d7ea5c3aac8970b9529775316507c6d2 upstream

Fix the problem that thermal_get_temp returns the cached value,
which causes the temperature in generic thermal never updates.

Signed-off-by: Zhang Rui 
Acked-by: Jean Delvare 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

ACPI: Reject below-freezing temperatures as invalid critical temperatures

2008-08-06T17:11:04+00:00

commit a39a2d7c72b358c6253a2ec28e17b023b7f6f41c upstream

My laptop thinks that it's a good idea to give -73C as the critical
CPU temperature.... which isn't the best thing since it causes a shutdown
right at bootup.

Temperatures below freezing are clearly invalid critical thresholds
so just reject these as such.

Signed-off-by: Arjan van de Ven 
Acked-by: Zhang Rui 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

bay: exit if notify handler cannot be installed

2008-08-06T17:11:02+00:00

commit 7efd52a407bed6a2b02015b8ebbff7beba155392 upstream

If acpi_install_notify_handler() for a bay device fails, the bay driver is
superfluous.  Most likely, another driver (like libata) is already caring
about this device anyway.  Furthermore,
register_hotplug_dock_device(acpi_handle) from the dock driver must not be
called twice with the same handler.  This would result in an endless loop
consuming 100% of CPU.  So clean up and exit.

Signed-off-by: Holger Macht 
Signed-off-by: Andrew Morton 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

cpufreq acpi: only call _PPC after cpufreq ACPI init funcs got called already

2008-08-01T18:50:58+00:00

commit a1531acd43310a7e4571d52e8846640667f4c74b upstream

Ingo Molnar provided a fix to not call _PPC at processor driver
initialization time in "[PATCH] ACPI: fix cpufreq regression" (git
commit e4233dec749a3519069d9390561b5636a75c7579)

But it can still happen that _PPC is called at processor driver
initialization time.

This patch should make sure that this is not possible anymore.

Signed-off-by: Thomas Renninger 
Cc: Andi Kleen 
Cc: Len Brown 
Cc: Dave Jones 
Cc: Ingo Molnar 
Cc: Venkatesh Pallipadi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ACPICA: Ignore ACPI table signature for Load() operator

2008-06-22T05:24:55+00:00

upstream bc45b1d39a925b56796bebf8a397a0491489d85c

Without this patch booting with acpi_osi="!Windows 2006" is required
for several machines to function properly with cpufreq
due to failure to load a Vista specific table with a bad signature.

Only "SSDT" is acceptable to the ACPI spec, but tables are
seen with OEMx and null sigs. Therefore, signature validation
is worthless.  Apparently MS ACPI accepts such signatures, ACPICA
must be compatible.

http://bugzilla.kernel.org/show_bug.cgi?id=9919
http://bugzilla.kernel.org/show_bug.cgi?id=10383
http://bugzilla.kernel.org/show_bug.cgi?id=10454
https://bugzilla.novell.com/show_bug.cgi?id=396311

Signed-off-by: Bob Moore 
Signed-off-by: Lin Ming 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

2.6.25 regression: powertop says 120K wakeups/sec

2008-05-10T04:40:41+00:00

commit 0fda6b403f0eca66ad8a7c946b3996e359100443 upstream

Patch to fix huge number of wakeups reported due to recent changes in
processor_idle.c. The problem was that the entry_method determination was
broken due to one of the recent commits (bc71bec91f987) causing
C1 entry to not to go to halt.

http://lkml.org/lkml/2008/3/22/124

Signed-off-by: Venkatesh Pallipadi 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman