<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/acpi, branch v2.6.28</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v2.6.28</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v2.6.28'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2008-12-19T09:38:32Z</updated>
<entry>
<title>ACPI: fix 2.6.28 acpi.debug_level regression</title>
<updated>2008-12-19T09:38:32Z</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bjorn.helgaas@hp.com</email>
</author>
<published>2008-11-13T23:30:13Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=e76f42761197dd6e9405e2eeb35932acfede115a'/>
<id>urn:sha1:e76f42761197dd6e9405e2eeb35932acfede115a</id>
<content type='text'>
acpi_early_init() was changed to over-write the cmdline param,
making it really inconvenient to set debug flags at boot-time.

Also,
This sets the default level to "info", which is what all the ACPI
drivers use.  So to enable messages from drivers, you only have to
supply the "layer" (a.k.a. "component").  For non-"info" ACPI core
and ACPI interpreter messages, you have to supply both level and
layer masks, as before.

Signed-off-by: Bjorn Helgaas &lt;bjorn.helgaas@hp.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
</entry>
<entry>
<title>ACPI toshiba: only register rfkill if bt is enabled</title>
<updated>2008-12-16T00:27:07Z</updated>
<author>
<name>Frederik Deweerdt</name>
<email>frederik.deweerdt@xprog.eu</email>
</author>
<published>2008-12-15T21:54:19Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=38aefbc585c5d86df101e7644bff2c47112783d4'/>
<id>urn:sha1:38aefbc585c5d86df101e7644bff2c47112783d4</id>
<content type='text'>
Part of the rfkill initialization was done whenever BT was on or not.  The
following patch checks for BT presence before registering the rfkill to
the input layer.  Some minor cleanups (&gt; 80 char lines) were also added in
the process.

On Tue, Oct 28, 2008 at 10:10:37PM +0300, Andrey Borzenkov wrote:
[...]
&gt; [   66.633036] toshiba_acpi: Toshiba Laptop ACPI Extras version 0.19
&gt; [   66.633054] toshiba_acpi:     HCI method: \_SB_.VALD.GHCI
&gt; [   66.637764] input: Toshiba RFKill Switch as /devices/virtual/input/input3
[...]
&gt; [  113.920753] ------------[ cut here ]------------
&gt; [  113.920828] kernel BUG at /home/bor/src/linux-git/net/rfkill/rfkill.c:347!
&gt; [  113.920845] invalid opcode: 0000 [#1]
&gt; [  113.920877] last sysfs file: /sys/devices/pci0000:00/0000:00:04.0/host0/target0:0:0/0:0:0:0/block/sda/size
&gt; [  113.920900] Dumping ftrace buffer:
&gt; [  113.920919]    (ftrace buffer empty)
&gt; [  113.920933] Modules linked in: af_packet irnet ppp_generic slhc ircomm_tty ircomm binfmt_misc loop dm_mirror dm_region_hash dm_log dm_round_robin dm_multipath dm_mod alim15x3 ide_core nvram toshiba cryptomgr aead crypto_blkcipher michael_mic crypto_algapi orinoco_cs orinoco hermes_dld hermes pcmcia firmware_class snd_ali5451 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device smsc_ircc2 snd_pcm_oss snd_pcm rtc_cmos irda snd_timer snd_mixer_oss rtc_core snd crc_ccitt yenta_socket rtc_lib rsrc_nonstatic i2c_ali1535 pcmcia_core pcspkr psmouse soundcore i2c_core evdev sr_mod snd_page_alloc alim1535_wdt cdrom fan sg video output toshiba_acpi rfkill thermal backlight ali_agp processor ac button input_polldev battery agpgart ohci_hcd usbcore reiserfs pata_ali libata sd_mod scsi_mod [last unloaded: scsi_wait_scan]
&gt; [  113.921765]
&gt; [  113.921785] Pid: 3272, comm: ipolldevd Not tainted (2.6.28-rc2-1avb #3) PORTEGE 4000
&gt; [  113.921801] EIP: 0060:[&lt;dfaa4683&gt;] EFLAGS: 00010246 CPU: 0
&gt; [  113.921854] EIP is at rfkill_force_state+0x53/0x90 [rfkill]
&gt; [  113.921870] EAX: 00000000 EBX: 00000000 ECX: 00000003 EDX: 00000000
&gt; [  113.921885] ESI: 00000000 EDI: ddd50300 EBP: d8d7af40 ESP: d8d7af24
&gt; [  113.921900]  DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
&gt; [  113.921918] Process ipolldevd (pid: 3272, ti=d8d7a000 task=d8d93c90 task.ti=d8d7a000)
&gt; [  113.921933] Stack:
&gt; [  113.921945]  d8d7af38 00000246 dfb029d8 dfb029c0 dfb029d8 dfb029c0 ddd50300 d8d7af5c
&gt; [  113.922014]  dfb018e2 01000246 01000000 ddd50300 ddd50314 ddabb8a0 d8d7af68 dfb381c1
&gt; [  113.922098]  00000000 d8d7afa4 c012ec0a 00000000 00000002 00000000 c012eba8 ddabb8c0
&gt; [  113.922240] Call Trace:
&gt; [  113.922240]  [&lt;dfb018e2&gt;] ? bt_poll_rfkill+0x5c/0x82 [toshiba_acpi]
&gt; [  113.922240]  [&lt;dfb381c1&gt;] ? input_polled_device_work+0x11/0x40 [input_polldev]
&gt; [  113.922240]  [&lt;c012ec0a&gt;] ? run_workqueue+0xea/0x1f0
&gt; [  113.922240]  [&lt;c012eba8&gt;] ? run_workqueue+0x88/0x1f0
&gt; [  113.922240]  [&lt;dfb381b0&gt;] ? input_polled_device_work+0x0/0x40 [input_polldev]
&gt; [  113.922240]  [&lt;c012f047&gt;] ? worker_thread+0x87/0xf0
&gt; [  113.922240]  [&lt;c0132b00&gt;] ? autoremove_wake_function+0x0/0x50
&gt; [  113.922240]  [&lt;c012efc0&gt;] ? worker_thread+0x0/0xf0
&gt; [  113.922240]  [&lt;c013280f&gt;] ? kthread+0x3f/0x80
&gt; [  113.922240]  [&lt;c01327d0&gt;] ? kthread+0x0/0x80
&gt; [  113.922240]  [&lt;c01040d7&gt;] ? kernel_thread_helper+0x7/0x10
&gt; [  113.922240] Code: 43 54 89 73 54 39 c6 74 11 89 d9 ba 01 00 00 00 b8 40 68 aa df e8 3e 35 69 e0 89 f8 e8 77 fd 85 e0 31 c0 83 c4 10 5b 5e 5f 5d c3 &lt;0f&gt; 0b eb fe 89 f6 8d bc 27 00 00 00 00 be f4 4d aa df bb 5f 01
&gt; [  113.922240] EIP: [&lt;dfaa4683&gt;] rfkill_force_state+0x53/0x90 [rfkill] SS:ESP 0068:d8d7af24
&gt; [  113.924700] ---[ end trace 0e404eb40cadd5f0 ]---

Signed-off-by: Frederik Deweerdt &lt;frederik.deweerdt@gmail.com&gt;
Tested-by: Andrey Borzenkov &lt;arvidjaar@mail.ru&gt;
Acked-by: Len Brown &lt;len.brown@intel.com&gt;
Cc: Richard Purdie &lt;rpurdie@rpsys.net&gt;
Acked-by: Philip Langdale &lt;philipl@overt.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>
</entry>
<entry>
<title>Revert "ACPI: battery: Convert discharge energy rate to current properly"</title>
<updated>2008-12-05T21:30:03Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2008-12-05T21:30:03Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f10a3a32ae2edbe94920ce6827f4c2550eb6ed48'/>
<id>urn:sha1:f10a3a32ae2edbe94920ce6827f4c2550eb6ed48</id>
<content type='text'>
This reverts commit 558073dd56707864f09d563b64e7c37c021e89d2, along with
the failed try to fix the regression it caused ("ACPI: Fix ACPI battery
regression introduced by commit 558073"), which just made things worse.

Commit aaad077638be1a25871bcae5e43952d6b63abfca (that failed "Fix ACPI
battery regression") got the voltage conversion confused, and fixed the
problem with Rafael's battery monitor apparently just by mistake.

So revert them both, getting us back to the 2.6.27 state in this, and
let's revisit it when people understand what's going on.

Noted-by: Paul Martin &lt;pm@debian.org&gt;
Requested-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;
Cc: Len Brown &lt;len.brown@intel.com&gt;
Cc: Alexey Starikovskiy &lt;astarikovskiy@suse.de&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>ACPI: Fix ACPI battery regression introduced by commit 558073</title>
<updated>2008-12-05T05:43:16Z</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rjw@sisk.pl</email>
</author>
<published>2008-12-05T00:07:51Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=aaad077638be1a25871bcae5e43952d6b63abfca'/>
<id>urn:sha1:aaad077638be1a25871bcae5e43952d6b63abfca</id>
<content type='text'>
Commit 558073dd56707864f09d563b64e7c37c021e89d2 ("ACPI: battery: Convert
discharge energy rate to current properly") caused the battery subsystem
to report wrong values of the remaining time on battery power and the
time until fully charged on Toshiba Portege R500 (and presumably on
other boxes too).

Fix the issue by correcting the conversion from mW to mA.

Signed-off-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>toshiba_acpi: close race in toshiba_acpi driver</title>
<updated>2008-11-28T19:21:53Z</updated>
<author>
<name>Arjan van de Ven</name>
<email>arjan@linux.intel.com</email>
</author>
<published>2008-11-28T16:19:09Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=23d0a65cf229acd273b6f5a325c34d758a90d592'/>
<id>urn:sha1:23d0a65cf229acd273b6f5a325c34d758a90d592</id>
<content type='text'>
the toshiba ACPI driver will, in a failure case, free the rfkill state
before stopping the polling timer that would use this state. More interesting,
in the same failure case handling, it calls the exit function, which also
frees the rfkill state, but after stopping the polling.

If the race happens, a NULL pointer is passed to rfkill_force_state()
which then causes a nice dereference.

Fix the race by just not doing the too-early freeing of the rfkill state.

This appears to be the cause of a hot issue on kerneloops.org; while I
have no solid evidence of that this patch will fix the issue, the race
appears rather real.

Signed-off-by: Arjan van de Ven &lt;arjan@linux.intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
</entry>
<entry>
<title>ACPI: delete OSI(Linux) DMI dmesg spam</title>
<updated>2008-11-27T06:55:21Z</updated>
<author>
<name>Len Brown</name>
<email>len.brown@intel.com</email>
</author>
<published>2008-11-08T06:21:10Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=a6e0887f21bbab337ee32d9c0a84d7c0b6e9141b'/>
<id>urn:sha1:a6e0887f21bbab337ee32d9c0a84d7c0b6e9141b</id>
<content type='text'>
Linux will continue to ignore OSI(Linux),
except for a white-list containing a few systems.

So delete the black-list,
and stop soliciting user-feedback on the console.

Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
</entry>
<entry>
<title>Revert "ACPI: don't enable control method power button as wakeup device when Fixed Power button is used"</title>
<updated>2008-11-26T22:55:15Z</updated>
<author>
<name>Len Brown</name>
<email>len.brown@intel.com</email>
</author>
<published>2008-11-26T22:55:15Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=3bdca1b863c1ebcb2244fc0cb683876d7330e62b'/>
<id>urn:sha1:3bdca1b863c1ebcb2244fc0cb683876d7330e62b</id>
<content type='text'>
This reverts commit faee816b1502385dc9bc5abf2960d1cc645844d1.

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

Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
</entry>
<entry>
<title>ACPI suspend: Blacklist boxes that require us to set SCI_EN directly on resume</title>
<updated>2008-11-26T22:53:13Z</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rjw@sisk.pl</email>
</author>
<published>2008-11-26T22:53:13Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=65df78473ffbf3bff5e2034df1638acc4f3ddd50'/>
<id>urn:sha1:65df78473ffbf3bff5e2034df1638acc4f3ddd50</id>
<content type='text'>
Some Apple boxes evidently require us to set SCI_EN on resume
directly, because if we don't do that, they hung somewhere in the
resume code path.  Moreover, on these boxes it is not sufficient to
use acpi_enable() to turn ACPI on during resume.  All of this is
against the ACPI specification which states that (1) the BIOS is
supposed to return from the S3 sleep state with ACPI enabled
(SCI_EN set) and (2) the SCI_EN bit is owned by the hardware and we
are not supposed to change it.

For this reason, blacklist the affected systems so that the SCI_EN
bit is set during resume on them.

[NOTE: Unconditional setting SCI_EN for all system on resume doesn't
 work, because it makes some other systems crash (that's to be
 expected).  Also, it is not entirely clear right now if all of the
 Apple boxes require this workaround.]

This patch fixes the recent regression tracked as
http://bugzilla.kernel.org/show_bug.cgi?id=12038

Signed-off-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;
Tested-by: Tino Keitel &lt;tino.keitel@gmx.de&gt;
Tested-by: Bob Copeland &lt;me@bobcopeland.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
</entry>
<entry>
<title>ACPI: scheduling in atomic via acpi_evaluate_integer ()</title>
<updated>2008-11-26T22:39:06Z</updated>
<author>
<name>Pavel Machek</name>
<email>pavel@suse.cz</email>
</author>
<published>2008-11-25T11:05:08Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=40599072dca3ec7d4c9ff8271978be169f974638'/>
<id>urn:sha1:40599072dca3ec7d4c9ff8271978be169f974638</id>
<content type='text'>
Now I know why I had strange "scheduling in atomic" problems:
acpi_evaluate_integer() does malloc(..., irqs_disabled() ? GFP_ATOMIC
: GFP_KERNEL)... which is (of course) broken.

There's no way to reliably tell if we need GFP_ATOMIC or not from
code, this one for example fails to detect spinlocks held.

Fortunately, allocation seems small enough to be done on stack.

Signed-off-by: Pavel Machek &lt;pavel@suse.cz&gt;
Acked-by: Bob Moore &lt;robert.moore@intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
</entry>
<entry>
<title>ACPI: battery: Convert discharge energy rate to current properly</title>
<updated>2008-11-26T22:23:10Z</updated>
<author>
<name>Alexey Starikovskiy</name>
<email>aystarik@gmail.com</email>
</author>
<published>2008-11-21T14:41:01Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=558073dd56707864f09d563b64e7c37c021e89d2'/>
<id>urn:sha1:558073dd56707864f09d563b64e7c37c021e89d2</id>
<content type='text'>
ACPI battery interface reports its state either in mW or in mA, and
discharge rate in your case is reported in mW. power_supply interface
does not have such a parameter, so current_now parameter is used
for all cases. But in case of mW, reported discharge should
be converted into mA.

Signed-off-by: Alexey Starikovskiy &lt;astarikovskiy@suse.de&gt;
Tested-by: Ferenc Wagner &lt;wferi@niif.hu&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
</entry>
</feed>
