<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/acpi, branch v2.6.25.2</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>acpi: bus: check once more for an empty list after locking it</title>
<updated>2008-04-16T02:35:41+00:00</updated>
<author>
<name>Chuck Ebbert</name>
<email>cebbert@redhat.com</email>
</author>
<published>2008-04-15T21:34:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f0a37e008750ead1751b7d5e89d220a260a46147'/>
<id>f0a37e008750ead1751b7d5e89d220a260a46147</id>
<content type='text'>
List could have become empty after the unlocked check that was made earlier,
so check again inside the lock.

Should fix https://bugzilla.redhat.com/show_bug.cgi?id=427765

Signed-off-by: Chuck Ebbert &lt;cebbert@redhat.com&gt;
Cc: &lt;stable@kernel.org&gt;
Cc: Len Brown &lt;lenb@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
List could have become empty after the unlocked check that was made earlier,
so check again inside the lock.

Should fix https://bugzilla.redhat.com/show_bug.cgi?id=427765

Signed-off-by: Chuck Ebbert &lt;cebbert@redhat.com&gt;
Cc: &lt;stable@kernel.org&gt;
Cc: Len Brown &lt;lenb@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>acpi: fix "buggy BIOS check" when CPUs are hot removed</title>
<updated>2008-04-09T01:25:53+00:00</updated>
<author>
<name>Alok Kataria</name>
<email>akataria@vmware.com</email>
</author>
<published>2008-04-09T00:41:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ba62b077871a5255e271f4fdae57167651839277'/>
<id>ba62b077871a5255e271f4fdae57167651839277</id>
<content type='text'>
Fixes a BUG in ACPI hotplugging.

processor_device_array[pr-&gt;id] needs to be set to NULL when removing a CPU.
Else the "buggy BIOS check" in acpi_processor_start mistakenly fires when a
CPU is removed from the system and then later re-added.

Signed-off-by: Alok N Kataria &lt;akataria@vmware.com&gt;
Signed-off-by: Dan Arai &lt;arai@vmware.com&gt;
Cc: Len Brown &lt;lenb@kernel.org&gt;
Cc: &lt;stable@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fixes a BUG in ACPI hotplugging.

processor_device_array[pr-&gt;id] needs to be set to NULL when removing a CPU.
Else the "buggy BIOS check" in acpi_processor_start mistakenly fires when a
CPU is removed from the system and then later re-added.

Signed-off-by: Alok N Kataria &lt;akataria@vmware.com&gt;
Signed-off-by: Dan Arai &lt;arai@vmware.com&gt;
Cc: Len Brown &lt;lenb@kernel.org&gt;
Cc: &lt;stable@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>acpi thermal: fix result check</title>
<updated>2008-04-09T01:25:52+00:00</updated>
<author>
<name>Krzysztof Helt</name>
<email>krzysztof.h1@wp.pl</email>
</author>
<published>2008-04-09T00:41:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=bb070e43497d4fcfea7d8b52003fe1376c218343'/>
<id>bb070e43497d4fcfea7d8b52003fe1376c218343</id>
<content type='text'>
thermal_zone_device_register() uses the ERR_PTR macro on its return values.  A
correct check is to use the IS_ERR() macro.

The 2.6.25 kernels panic on Compaq AP550 without this patch as it has more
then 10 (THERMAL_MAX_TRIPS) trip points (there are 12).

Signed-off-by: Krzysztof Helt &lt;krzysztof.h1@wp.pl&gt;
Cc: "Rafael J. Wysocki" &lt;rjw@sisk.pl&gt;
Cc: Len Brown &lt;lenb@kernel.org&gt;
Acked-by: Zhang Rui &lt;rui.zhang@intel.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
thermal_zone_device_register() uses the ERR_PTR macro on its return values.  A
correct check is to use the IS_ERR() macro.

The 2.6.25 kernels panic on Compaq AP550 without this patch as it has more
then 10 (THERMAL_MAX_TRIPS) trip points (there are 12).

Signed-off-by: Krzysztof Helt &lt;krzysztof.h1@wp.pl&gt;
Cc: "Rafael J. Wysocki" &lt;rjw@sisk.pl&gt;
Cc: Len Brown &lt;lenb@kernel.org&gt;
Acked-by: Zhang Rui &lt;rui.zhang@intel.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "ACPI: Ignore _BQC object when registering backlight device"</title>
<updated>2008-04-05T19:14:13+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2008-04-05T19:14:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=797de7bdb253624c16144f40b72ec65d63cdcca2'/>
<id>797de7bdb253624c16144f40b72ec65d63cdcca2</id>
<content type='text'>
This reverts commit 7c0ea45be4f114d85ee35caeead8e1660699c46f which
caused a regression with the backlight being set to off when a laptop
doesn't have a _BQC entry to query the actual backlight value.  The code
blindly then falls back on a value of 0.

See
	http://bugzilla.kernel.org/show_bug.cgi?id=10387
	http://lkml.org/lkml/2008/4/2/366

for details.

Bisected-and-reported-by: Andrey Borzenkov &lt;arvidjaar@mail.ru&gt;
Cc: Zhao Yakui &lt;yakui.zhao@intel.com&gt;
Cc: Zhang Rui &lt;rui.zhang@intel.com&gt;
Cc: Len Brown &lt;len.brown@intel.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 7c0ea45be4f114d85ee35caeead8e1660699c46f which
caused a regression with the backlight being set to off when a laptop
doesn't have a _BQC entry to query the actual backlight value.  The code
blindly then falls back on a value of 0.

See
	http://bugzilla.kernel.org/show_bug.cgi?id=10387
	http://lkml.org/lkml/2008/4/2/366

for details.

Bisected-and-reported-by: Andrey Borzenkov &lt;arvidjaar@mail.ru&gt;
Cc: Zhao Yakui &lt;yakui.zhao@intel.com&gt;
Cc: Zhang Rui &lt;rui.zhang@intel.com&gt;
Cc: Len Brown &lt;len.brown@intel.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI PM: Restore the 2.6.24 suspend ordering</title>
<updated>2008-04-01T18:21:08+00:00</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rjw@sisk.pl</email>
</author>
<published>2008-03-30T01:19:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=7731ce63d9a863c987dd87b0425451fff0e6cdc8'/>
<id>7731ce63d9a863c987dd87b0425451fff0e6cdc8</id>
<content type='text'>
Some time ago it turned out that our suspend code ordering broke some
NVidia-based systems that hung if _PTS was executed with one of the PCI
devices, specifically a USB controller, in a low power state.

Then, it was noticed that the suspend code ordering was not compliant
with ACPI 1.0, although it was compliant with ACPI 2.0 (and later), and
it was argued that the code had to be changed for that reason (ref.
http://bugzilla.kernel.org/show_bug.cgi?id=9528).

So we did, but evidently we did wrong, because it's now turning out that
some systems have been broken by this change. Refs:
	http://bugzilla.kernel.org/show_bug.cgi?id=10340
	https://bugzilla.novell.com/show_bug.cgi?id=374217#c16

[ I said at that time that something like this might happend, but the
  majority of people involved thought that it was improbable due to the
  necessity to preserve the compliance of hardware with ACPI 1.0. ]

This actually is a quite serious regression from 2.6.24.

Moreover, the ACPI 1.0 ordering of suspend code introduced another issue
that I have only noticed recently.  Namely, if the suspend of one of
devices fails, the already suspended devices will be resumed without
executing _WAK before, which leads to problems on some systems (for
example, in such situations thermal management is broken on my HP
nx6325).  Consequently, it also breaks suspend debugging on the affected
systems.

Note also, that the requirement to execute _PTS before suspending
devices does not really make sense, because the device in question may
be put into a low power state at run time for a reason unrelated to a
system-wide suspend.

For the reasons outlined above, the change of the suspend ordering
should be reverted, which is done by the patch below.

[ Felix Möller: "I am the reporter from the original Novell Bug:

	https://bugzilla.novell.com/show_bug.cgi?id=374217

  I just tried current git head (two hours ago) with the patch (the one
  from the beginning of this thread) from Rafael and without it.  With
  the patch my MacBook does suspend without it does not." ]

Signed-off-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;
Tested-by: Felix Möller &lt;felix@derklecks.de&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some time ago it turned out that our suspend code ordering broke some
NVidia-based systems that hung if _PTS was executed with one of the PCI
devices, specifically a USB controller, in a low power state.

Then, it was noticed that the suspend code ordering was not compliant
with ACPI 1.0, although it was compliant with ACPI 2.0 (and later), and
it was argued that the code had to be changed for that reason (ref.
http://bugzilla.kernel.org/show_bug.cgi?id=9528).

So we did, but evidently we did wrong, because it's now turning out that
some systems have been broken by this change. Refs:
	http://bugzilla.kernel.org/show_bug.cgi?id=10340
	https://bugzilla.novell.com/show_bug.cgi?id=374217#c16

[ I said at that time that something like this might happend, but the
  majority of people involved thought that it was improbable due to the
  necessity to preserve the compliance of hardware with ACPI 1.0. ]

This actually is a quite serious regression from 2.6.24.

Moreover, the ACPI 1.0 ordering of suspend code introduced another issue
that I have only noticed recently.  Namely, if the suspend of one of
devices fails, the already suspended devices will be resumed without
executing _WAK before, which leads to problems on some systems (for
example, in such situations thermal management is broken on my HP
nx6325).  Consequently, it also breaks suspend debugging on the affected
systems.

Note also, that the requirement to execute _PTS before suspending
devices does not really make sense, because the device in question may
be put into a low power state at run time for a reason unrelated to a
system-wide suspend.

For the reasons outlined above, the change of the suspend ordering
should be reverted, which is done by the patch below.

[ Felix Möller: "I am the reporter from the original Novell Bug:

	https://bugzilla.novell.com/show_bug.cgi?id=374217

  I just tried current git head (two hours ago) with the patch (the one
  from the beginning of this thread) from Rafael and without it.  With
  the patch my MacBook does suspend without it does not." ]

Signed-off-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;
Tested-by: Felix Möller &lt;felix@derklecks.de&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>revert "ACPI: drivers/acpi: elide a non-zero test on a result that is never 0"</title>
<updated>2008-03-28T17:16:53+00:00</updated>
<author>
<name>Ingo Molnar</name>
<email>mingo@elte.hu</email>
</author>
<published>2008-03-28T13:28:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=48d3d8263c491822d50e64547bae5f6b4a54ec59'/>
<id>48d3d8263c491822d50e64547bae5f6b4a54ec59</id>
<content type='text'>
Revert commit 1192aeb957402b45f311895f124e4ca41206843c ("ACPI:
drivers/acpi: elide a non-zero test on a result that is never 0")
because it turns out that thermal_cooling_device_register() does
actually return NULL if CONFIG_THERMAL is turned off (then the routine
turns into a dummy inline routine in the header files that returns NULL
unconditionally).

This was found with randconfig testing, causing a crash during bootup:

  initcall 0x78878534 ran for 13 msecs: acpi_button_init+0x0/0x51()
  Calling initcall 0x78878585: acpi_fan_init+0x0/0x2c()
  BUG: unable to handle kernel NULL pointer dereference at 00000000
  IP: [&lt;782b8ad0&gt;] acpi_fan_add+0x7d/0xfd
  *pde = 00000000
  Oops: 0000 [#1]
  Modules linked in:

  Pid: 1, comm: swapper Not tainted (2.6.25-rc7-sched-devel.git-x86-latest.git #14)
  EIP: 0060:[&lt;782b8ad0&gt;] EFLAGS: 00010246 CPU: 0
  EIP is at acpi_fan_add+0x7d/0xfd
  EAX: b787c718 EBX: b787c400 ECX: b782ceb4 EDX: 00000007
  ESI: 00000000 EDI: b787c6f4 EBP: b782cee0 ESP: b782cecc
   DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
  Process swapper (pid: 1, ti=b782c000 task=b7846000 task.ti=b782c000)
  Stack: b787c459 00000000 b787c400 78790888 b787c60c b782cef8 782b6fb8 ffffffda
         b787c60c 00000000 78790958 b782cf0c 783005d7 b787c60c 78790958 78790584
         b782cf1c 783007f6 b782cf28 00000000 b782cf40 782ffc4a 78790958 b794d558
  Call Trace:
   [&lt;782b6fb8&gt;] ? acpi_device_probe+0x3e/0xdb
   [&lt;783005d7&gt;] ? driver_probe_device+0x82/0xfc
   [&lt;783007f6&gt;] ? __driver_attach+0x3a/0x70
   [&lt;782ffc4a&gt;] ? bus_for_each_dev+0x3e/0x60
   [&lt;7830048c&gt;] ? driver_attach+0x14/0x16
   [&lt;783007bc&gt;] ? __driver_attach+0x0/0x70
   [&lt;7830006a&gt;] ? bus_add_driver+0x9d/0x1b0
   [&lt;783008c3&gt;] ? driver_register+0x47/0xa3
   [&lt;7813db00&gt;] ? timespec_to_ktime+0x9/0xc
   [&lt;782b7331&gt;] ? acpi_bus_register_driver+0x3a/0x3c
   [&lt;78878592&gt;] ? acpi_fan_init+0xd/0x2c
   [&lt;78863656&gt;] ? kernel_init+0xac/0x1f9
   [&lt;788635aa&gt;] ? kernel_init+0x0/0x1f9
   [&lt;78114563&gt;] ? kernel_thread_helper+0x7/0x10
   =======================
  Code: 6e 78 e8 57 44 e7 ff 58 e9 93 00 00 00 8b 55 f0 8d bb f4 02 00 00 80 4b 2d 10 8b 03 e8 87 cb ff ff 8d 83 18 03 00 00 80 63 2d ef &lt;ff&gt; 35 00 00 00 00 50 68 e8 9c 6e 78 e8 22 44 e7 ff b9 b6 9c 6e
  EIP: [&lt;782b8ad0&gt;] acpi_fan_add+0x7d/0xfd SS:ESP 0068:b782cecc
  ---[ end trace 778e504de7e3b1e3 ]---
  Kernel panic - not syncing: Attempted to kill init!

Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Acked-by: Julia Lawall &lt;julia@diku.dk&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Revert commit 1192aeb957402b45f311895f124e4ca41206843c ("ACPI:
drivers/acpi: elide a non-zero test on a result that is never 0")
because it turns out that thermal_cooling_device_register() does
actually return NULL if CONFIG_THERMAL is turned off (then the routine
turns into a dummy inline routine in the header files that returns NULL
unconditionally).

This was found with randconfig testing, causing a crash during bootup:

  initcall 0x78878534 ran for 13 msecs: acpi_button_init+0x0/0x51()
  Calling initcall 0x78878585: acpi_fan_init+0x0/0x2c()
  BUG: unable to handle kernel NULL pointer dereference at 00000000
  IP: [&lt;782b8ad0&gt;] acpi_fan_add+0x7d/0xfd
  *pde = 00000000
  Oops: 0000 [#1]
  Modules linked in:

  Pid: 1, comm: swapper Not tainted (2.6.25-rc7-sched-devel.git-x86-latest.git #14)
  EIP: 0060:[&lt;782b8ad0&gt;] EFLAGS: 00010246 CPU: 0
  EIP is at acpi_fan_add+0x7d/0xfd
  EAX: b787c718 EBX: b787c400 ECX: b782ceb4 EDX: 00000007
  ESI: 00000000 EDI: b787c6f4 EBP: b782cee0 ESP: b782cecc
   DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
  Process swapper (pid: 1, ti=b782c000 task=b7846000 task.ti=b782c000)
  Stack: b787c459 00000000 b787c400 78790888 b787c60c b782cef8 782b6fb8 ffffffda
         b787c60c 00000000 78790958 b782cf0c 783005d7 b787c60c 78790958 78790584
         b782cf1c 783007f6 b782cf28 00000000 b782cf40 782ffc4a 78790958 b794d558
  Call Trace:
   [&lt;782b6fb8&gt;] ? acpi_device_probe+0x3e/0xdb
   [&lt;783005d7&gt;] ? driver_probe_device+0x82/0xfc
   [&lt;783007f6&gt;] ? __driver_attach+0x3a/0x70
   [&lt;782ffc4a&gt;] ? bus_for_each_dev+0x3e/0x60
   [&lt;7830048c&gt;] ? driver_attach+0x14/0x16
   [&lt;783007bc&gt;] ? __driver_attach+0x0/0x70
   [&lt;7830006a&gt;] ? bus_add_driver+0x9d/0x1b0
   [&lt;783008c3&gt;] ? driver_register+0x47/0xa3
   [&lt;7813db00&gt;] ? timespec_to_ktime+0x9/0xc
   [&lt;782b7331&gt;] ? acpi_bus_register_driver+0x3a/0x3c
   [&lt;78878592&gt;] ? acpi_fan_init+0xd/0x2c
   [&lt;78863656&gt;] ? kernel_init+0xac/0x1f9
   [&lt;788635aa&gt;] ? kernel_init+0x0/0x1f9
   [&lt;78114563&gt;] ? kernel_thread_helper+0x7/0x10
   =======================
  Code: 6e 78 e8 57 44 e7 ff 58 e9 93 00 00 00 8b 55 f0 8d bb f4 02 00 00 80 4b 2d 10 8b 03 e8 87 cb ff ff 8d 83 18 03 00 00 80 63 2d ef &lt;ff&gt; 35 00 00 00 00 50 68 e8 9c 6e 78 e8 22 44 e7 ff b9 b6 9c 6e
  EIP: [&lt;782b8ad0&gt;] acpi_fan_add+0x7d/0xfd SS:ESP 0068:b782cecc
  ---[ end trace 778e504de7e3b1e3 ]---
  Kernel panic - not syncing: Attempted to kill init!

Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Acked-by: Julia Lawall &lt;julia@diku.dk&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI: drivers/acpi: elide a non-zero test on a result that is never 0</title>
<updated>2008-03-27T05:48:22+00:00</updated>
<author>
<name>Julia Lawall</name>
<email>julia@diku.dk</email>
</author>
<published>2008-03-27T05:48:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1192aeb957402b45f311895f124e4ca41206843c'/>
<id>1192aeb957402b45f311895f124e4ca41206843c</id>
<content type='text'>
The function thermal_cooling_device_register always returns either a valid
pointer or a value made with ERR_PTR, so a test for non-zero on the result
will always succeed.

The problem was found using the following semantic match.
(http://www.emn.fr/x-info/coccinelle/)

//&lt;smpl&gt;
@a@
expression E, E1;
statement S,S1;
position p;
@@

E = thermal_cooling_device_register(...)
... when != E = E1
if@p (E) S else S1

@n@
position a.p;
expression E,E1;
statement S,S1;
@@

E = NULL
... when != E = E1
if@p (E) S else S1

@depends on !n@
expression E;
statement S,S1;
position a.p;
@@

* if@p (E)
  S else S1
//&lt;/smpl&gt;

Signed-off-by: Julia Lawall &lt;julia@diku.dk&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The function thermal_cooling_device_register always returns either a valid
pointer or a value made with ERR_PTR, so a test for non-zero on the result
will always succeed.

The problem was found using the following semantic match.
(http://www.emn.fr/x-info/coccinelle/)

//&lt;smpl&gt;
@a@
expression E, E1;
statement S,S1;
position p;
@@

E = thermal_cooling_device_register(...)
... when != E = E1
if@p (E) S else S1

@n@
position a.p;
expression E,E1;
statement S,S1;
@@

E = NULL
... when != E = E1
if@p (E) S else S1

@depends on !n@
expression E;
statement S,S1;
position a.p;
@@

* if@p (E)
  S else S1
//&lt;/smpl&gt;

Signed-off-by: Julia Lawall &lt;julia@diku.dk&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branches 'release', 'idle', 'redhat-bugzilla-436589', 'sbs' and 'video' into release</title>
<updated>2008-03-27T02:50:09+00:00</updated>
<author>
<name>Len Brown</name>
<email>len.brown@intel.com</email>
</author>
<published>2008-03-27T02:50:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=86d9fc1293aa9456677eab94e9fd2d3a10920548'/>
<id>86d9fc1293aa9456677eab94e9fd2d3a10920548</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>cpuidle: fix 100% C0 statistics regression</title>
<updated>2008-03-26T04:58:19+00:00</updated>
<author>
<name>Venki Pallipadi</name>
<email>venkatesh.pallipadi@intel.com</email>
</author>
<published>2008-02-29T18:24:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8e92b6605da989c0aa8ff7e33306f36f0efd957c'/>
<id>8e92b6605da989c0aa8ff7e33306f36f0efd957c</id>
<content type='text'>
commit 9b12e18cdc1553de62d931e73443c806347cd974
'ACPI: cpuidle: Support C1 idle time accounting'
was implicated in a 100% C0 idle regression.
http://bugzilla.kernel.org/show_bug.cgi?id=10076

It pointed out a potential problem where the menu governor
may get confused by the C-state residency time from poll
idle or C1 idle, where this timing info is not accurate.
This inaccuracy is due to interrupts being handled
before we account for C-state exit.

Do not mark TIME_VALID for CO poll state.
Mark C1 time as valid only with the MWAIT (CSTATE_FFH) entry method.

This makes governors use the timing information only when it is correct and
eliminates any wrong policy decisions that may result from invalid timing
information.

Signed-off-by: Venkatesh Pallipadi &lt;venkatesh.pallipadi@intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9b12e18cdc1553de62d931e73443c806347cd974
'ACPI: cpuidle: Support C1 idle time accounting'
was implicated in a 100% C0 idle regression.
http://bugzilla.kernel.org/show_bug.cgi?id=10076

It pointed out a potential problem where the menu governor
may get confused by the C-state residency time from poll
idle or C1 idle, where this timing info is not accurate.
This inaccuracy is due to interrupts being handled
before we account for C-state exit.

Do not mark TIME_VALID for CO poll state.
Mark C1 time as valid only with the MWAIT (CSTATE_FFH) entry method.

This makes governors use the timing information only when it is correct and
eliminates any wrong policy decisions that may result from invalid timing
information.

Signed-off-by: Venkatesh Pallipadi &lt;venkatesh.pallipadi@intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI: fix mis-merge -- invoke acpi_unlazy_tlb() only on C3 entry</title>
<updated>2008-03-26T04:40:41+00:00</updated>
<author>
<name>Venki Pallipadi</name>
<email>venkatesh.pallipadi@intel.com</email>
</author>
<published>2008-03-24T21:24:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=996520c1fdd2948addb629be56c9febf2967e02b'/>
<id>996520c1fdd2948addb629be56c9febf2967e02b</id>
<content type='text'>
This original patch
http://ussg.iu.edu/hypermail/linux/kernel/0712.2/1451.html
was intending to add acpi_unlazy_tlb() to acpi_idle_enter_bm(),
which is used for C3 entry.

But it was merged incorrectly as commmit

bde6f5f59c2b2b48a7a849c129d5b48838fe77ee
'x86: voluntary leave_mm before entering ACPI C3'

so the call was instead added to acpi_idle_enter_simple()
(which is C2 entry routine), probably due to identical
context in that function.

Move the call back to acpi_idle_enter_bm().

Signed-off-by: Venkatesh Pallipadi &lt;venkatesh.pallipadi@intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This original patch
http://ussg.iu.edu/hypermail/linux/kernel/0712.2/1451.html
was intending to add acpi_unlazy_tlb() to acpi_idle_enter_bm(),
which is used for C3 entry.

But it was merged incorrectly as commmit

bde6f5f59c2b2b48a7a849c129d5b48838fe77ee
'x86: voluntary leave_mm before entering ACPI C3'

so the call was instead added to acpi_idle_enter_simple()
(which is C2 entry routine), probably due to identical
context in that function.

Move the call back to acpi_idle_enter_bm().

Signed-off-by: Venkatesh Pallipadi &lt;venkatesh.pallipadi@intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
