debian kernel 2.6.24-1 output
Hi, ACPI: EC: EC description table is found, configuring boot EC ACPI: EC: non-query interrupt received, switching to interrupt mode ACPI: BIOS _OSI(Linux) query ignored ACPI: DMI System Vendor: Apple Inc. ACPI: DMI Product Name: MacBookPro3,1 ACPI: DMI Product Version: 1.0 ACPI: DMI Board Name: Mac-F4238BC8 ACPI: DMI BIOS Vendor: Apple Inc. ACPI: DMI BIOS Date: 06/18/07 ACPI: Please send DMI info above to linux-acpi@vger.kernel.org ACPI: If acpi_osi=Linux works better, please notify linux-acpi@vger.kernel.org I have not yet tried with acpi_osi=Linux. Cheers, -- Eugen Dedu - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Override DSDT and SSDTs via initramfs
On Wed, 2008-01-30 at 23:36 +0100, Éric Piel wrote: Hi, Just a few comments for now as I don't have much time until this weekend. 30/01/08 18:27, Thomas Renninger wrote/a écrit: : On Fri, 2008-01-25 at 23:39 -0500, Len Brown wrote: : Probably it is best to forward the original patch w/ proper credits, and then send updates to address 1-4. Thomas, the patch you have included is only the original patch, right? We need to address the points 1-4 (which seem very reasonable) later on with additional patches. I think most of them are already implemented in http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initrd-v0.8.2-2.6.17-ssdt.patch So that should be quite easy :-) I do not know who initially came up with this, I just modified/adjusted the patch sometimes. I expect it's Markus, possibly Eric or best both who should be mentioned as author. Yep, to be precise, Markus Gaugusch is the original author, I'm just the current maintainer, and Thomas has been very helpful for a looong time :-) Long time is true..., very helpful, don't know, I didn't do that much... Jeff (Mahony) has adjusted the last bits of it when he updated it to the latest rcX-gitY version: Changes: We no longer call populate_rootfs() twice. If we want the custom DSDT, we load the rootfs before ACPI. Otherwise, it is loaded at the appropriate initcall time. -jeffm I had left it this way because I though Linus had a good reason for delaying populate_rootfs(). But if it works, fine! Maybe some additional comments should be added in before the #ifdef's to clearly show that populate_rootfs() is _always_ called, and they modify only the moment it is called. I don't know about this, I took that change from your patches... There is a new version at http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initrd-v0.8.4-2.6.21.patch, but there doesn't seem to be any real changes other than elminating the file name array. Yes, exactly. In fact, I added the array some time ago. Not sure whether the latest Version of Eric/Markus can also load several DSDT/SSDTs? Maybe you found a more elegant way? Nope. On the website (http://gaugusch.at/kernel.shtml) you can just find two versions of the patch: one simple and one with your addition for SSDTs support. At least with SSDTs support there is even an advantage over the DSDT-in-kernel version :-) Just one comment about the patch for now: it misses Documentation/dsdt-initrd.txt . Please include this file too so that the documentation is provided at the same time (it's in the official patch). I'll test the patch and try to be productive this weekend. There is no real need for testing the patch. It is in OpenSUSE for quite some time. While I don't know how much it got used, it shouldn't break anything if unused. As Jeff stated (I haven't had a look at your current version) it should be nearly the same. About Len's points 1-4: 1. tainted bit needs to be set when a DSDT override is used. (this is common both to the new patch and the current override method) 2. upon setting the tainted bit, print a BIG FAT WARNING that this is not a supported configuration. 3. cmdline option needs to be available to disable an override. Otherwise a bad image in the intrd may be a serious pickle for some users. 4. get rid of alarming failure message: + printk(KERN_INFO Looking for DSDT in initrd ...); ... + printk( not found!\n); Most of this should be included in the one I sent: 1+2 should be covered by this: + printk(PREFIX Override [%4.4s-%8.8s] + from initramfs - + tainting kernel\n, + t-signature, + t-oem_table_id); + add_taint(TAINT_NO_SUPPORT); I remember that I introduced a new TAINT flag, this got probably ripped out because I expect it needed conflict solving with new kernels all the time. Now when it goes mainline a TAINT_DSDT_OVERRIDE flag might be appropriate, so that if you see a kernel panic or whatever bug, you immediately see why the kernel is tainted. Problem from 4. should also not exist in this patch anymore. The boot parameter (3.) is still missing. Eric, would you mind bringing this all together (if Len agrees with my aspects). I'd vote for moving the current location of the DSDT file to: /dsdt/DSDT.aml This would break current userspace apps (including SuSE's mkinitrd), but would prepare the patch for further SSDT enhancements. Thomas - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Override DSDT and SSDTs via initramfs
On Thu, 2008-01-31 at 14:17 -0500, Len Brown wrote: In fact, I added the array some time ago. Not sure whether the latest Version of Eric/Markus can also load several DSDT/SSDTs? Maybe you found a more elegant way? Nope. On the website (http://gaugusch.at/kernel.shtml) you can just find two versions of the patch: one simple and one with your addition for SSDTs support. At least with SSDTs support there is even an advantage over the DSDT-in-kernel version :-) At one point there was a proposal to allow in-kernel SSDT overrides, but we determined that it was problematic because there can be any number of SSDTs (so which one does an override apply to?), some of them auto loaded at RSDT time, and the others loaded at run-time via Load() in the DSDT (and possibly SSDT) AML. Yes and this is easy to solve via initrd. So we decided that to override an SSDT, you need to override a DSDT, incorporate whatever SSDT code you want into your DSDT, and boot with the acpi_no_auto_ssdt cmdline parameter to inhibit autoloading of the RSDT enumerated SSDTs. That gives you complete and total control over what AML gets run. (you omit that cmdline param to overide the DSDT but keep the native SSDTs) It also gives you just 1 DSDT to keep track of. I know and it's a rather complex way. You need to open the DSDT and copy and paste in an editor all SSDTs into DSDT (inside the last bracket, the global namespace, so simply attaching it at the very end is not working). Is that correct? That gives you complete and total control over what AML gets run I doubt that. You said there can be any number of SSDTs. If you know what you are doing..., but how do you explain someone in a bug that he has to collect all SSDTs (some via acpidump --addr xy) open an editor, paste them into the DSDT and so on... I know what you mean and in what pits you could fall, because I've tried it already, but... I'm not clear on how to use the proposed initrd SSDT override capability, and why it needs to be different from the simple scheme above, ... it is far away from a simple scheme, sorry. but I wouldn't want a mess there to hold up the rest of the initrd DSDT override patch series -- since only very rarely is an SSDT override needed. That's true, it's not needed that often and the patch shouldn't be hold off because of that. Let me explain again what the intend is: You pass to initrd e.g.: / /DSDT.aml /SSDT1.aml /SSDT2.aml (maybe it should be done in an own dsdt directory. Like that, one could check for each file in this directory, instead of the static array files that get checked, hmmm this possibly should decided now to avoid incompatibilities). Anyway, say you have a directory: /dsdt with two SSDTs sitting there that get loaded before any other table gets loaded. Those tables have been extracted with acpidump, disassembled with iasl -d, modified (e.g. added some debug code to get printed to syslog) and recompiled. Those tables have the same OEM id then the original ones, right? Tables with the same OEM id (the original ones) should get ignored later automatically. IIRC I had some problems with dynamically loaded tables, don't know anymore, they are not that often used and theoretically it should just work for them also. I haven't tried too much here, but SSDTs are used more and more often (I saw a machine with 12 SSDTs, especially on IA64 there might be dozens in the future). We should think about the problem now, before we have bugs and need to write down half a book how the reporter finally could provide some useful information. Have I overseen something? Thomas - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Override DSDT and SSDTs via initramfs
Thomas Renninger wrote: About Len's points 1-4: 1. tainted bit needs to be set when a DSDT override is used. (this is common both to the new patch and the current override method) 2. upon setting the tainted bit, print a BIG FAT WARNING that this is not a supported configuration. 3. cmdline option needs to be available to disable an override. Otherwise a bad image in the intrd may be a serious pickle for some users. 4. get rid of alarming failure message: + printk(KERN_INFO Looking for DSDT in initrd ...); ... + printk( not found!\n); Most of this should be included in the one I sent: 1+2 should be covered by this: + printk(PREFIX Override [%4.4s-%8.8s] + from initramfs - + tainting kernel\n, + t-signature, + t-oem_table_id); + add_taint(TAINT_NO_SUPPORT); I remember that I introduced a new TAINT flag, this got probably ripped out because I expect it needed conflict solving with new kernels all the time. Now when it goes mainline a TAINT_DSDT_OVERRIDE flag might be appropriate, so that if you see a kernel panic or whatever bug, you immediately see why the kernel is tainted. Problem from 4. should also not exist in this patch anymore. The boot parameter (3.) is still missing. Indeed, points 2 and 4 are already solved in your patch :-) Eric, would you mind bringing this all together (if Len agrees with my aspects). I'd vote for moving the current location of the DSDT file to: /dsdt/DSDT.aml This would break current userspace apps (including SuSE's mkinitrd), but would prepare the patch for further SSDT enhancements. Ok, I'll try to have something ready by the beginning of next week. I'm waiting from Len for his comments on the best names of the files and the SSDTs inclusion... See you, Eric - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
dmidecode for HP Pavilion dv9413cl
Host OS: openSuSE 10.3 linux version 2.6.22.16-0.1-default dmidecode Description: Binary data
Re: [PATCH] Override DSDT and SSDTs via initramfs
Thomas Renninger wrote: On Thu, 2008-01-31 at 14:17 -0500, Len Brown wrote: [skipped] Those tables have the same OEM id then the original ones, right? Tables with the same OEM id (the original ones) should get ignored later automatically. IIRC I had some problems with dynamically loaded tables, don't know anymore, they are not that often used and theoretically it should just work for them also. Comparing SSDT by their OEM ID is proved to not work. Right now, code checks the whole length of the table to be the same, and only then does not load it. It is not the case with any of modified tables, so original tables will be tried to load as well. I haven't tried too much here, but SSDTs are used more and more often (I saw a machine with 12 SSDTs, especially on IA64 there might be dozens in the future). We should think about the problem now, before we have bugs and need to write down half a book how the reporter finally could provide some useful information. Have I overseen something? Thomas - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need to replace one patch in suspend branch
On Friday, 1 of February 2008, Len Brown wrote:
On Monday 28 January 2008 18:29, Rafael J. Wysocki wrote:
Hi Len,
Would it be possible to replace commit
a04ca6718960e842624833a01dbd5f10f38f5af1
Suspend: Testing facility (rev. 2) in the suspend branch with the
appended patch?
Unfortunately, the original commit uses pointers to 'struct kset' which is
no
longer valid after the recently merged driver core changes.
Hi Rafael,
The original suspend branch is now available rooted at 2.6.24
as suspend-2.6.24.
The latest suspend branch is now based on today's linus HEAD.
Thanks a lot for doing that!
In the suspend branch, I rewound the series until after the
original patch, patch -R the original, patch -N the new one,
and checked in the the resulting diff (below).
At the expense of the additional trivial patch,
this struck me as a good balance between preserving
the (tested) history, showing what changed,
and minimizing exposure to bisect build breakage.
Yes, this is a good idea to add this additional patch after the original one.
Thanks,
Rafael
commit 21779c8de31b1c9e749af676a033109f70156678
Author: Rafael J. Wysocki [EMAIL PROTECTED]
Date: Tue Jan 29 00:29:06 2008 +0100
suspend: build fix responding to 2.6.25 kset change
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Signed-off-by: Len Brown [EMAIL PROTECTED]
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 84e1ae6..fc717b8 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -53,7 +53,8 @@ static const char * const pm_tests[__TEST_AFTER_LAST] = {
[TEST_FREEZER] = freezer,
};
-static ssize_t pm_test_show(struct kset *kset, char *buf)
+static ssize_t pm_test_show(struct kobject *kobj, struct kobj_attribute
*attr,
+ char *buf)
{
char *s = buf;
int level;
@@ -73,7 +74,8 @@ static ssize_t pm_test_show(struct kset *kset, char *buf)
return (s - buf);
}
-static ssize_t pm_test_store(struct kset *kset, const char *buf, size_t n)
+static ssize_t pm_test_store(struct kobject *kobj, struct kobj_attribute
*attr,
+ const char *buf, size_t n)
{
const char * const *s;
int level;
@@ -104,6 +106,7 @@ power_attr(pm_test);
static inline int suspend_test(int level) { return 0; }
#endif /* !CONFIG_PM_DEBUG */
+
#ifdef CONFIG_SUSPEND
/* This is just an arbitrary number */
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Override DSDT and SSDTs via initramfs
On Fri, 2008-02-01 at 14:07 +0300, Alexey Starikovskiy wrote: Thomas Renninger wrote: On Thu, 2008-01-31 at 14:17 -0500, Len Brown wrote: [skipped] Those tables have the same OEM id then the original ones, right? Tables with the same OEM id (the original ones) should get ignored later automatically. IIRC I had some problems with dynamically loaded tables, don't know anymore, they are not that often used and theoretically it should just work for them also. Comparing SSDT by their OEM ID is proved to not work. Right now, code checks the whole length of the table to be the same, and only then does not load it. It is not the case with any of modified tables, so original tables will be tried to load as well. Ahh, now when you say it, I remember about this darkly... What a pity..., maybe just comparing the whole header (without the checksum) could be an option? Or only do this if dsdt_got_overridden flag is set (ugly, but should be sufficient). Thomas I haven't tried too much here, but SSDTs are used more and more often (I saw a machine with 12 SSDTs, especially on IA64 there might be dozens in the future). We should think about the problem now, before we have bugs and need to write down half a book how the reporter finally could provide some useful information. Have I overseen something? Damn, I have :( Thomas - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-git9 ACPI oops - regression
[Relevant CCs added.] On Friday, 1 of February 2008, Lukas Hejtmanek wrote: Hello, I encountered oops on my laptop Lenovo T61 and dock. If I press undock on the dock, I got the following oops: [79721.755165] BUG: unable to handle kernel paging request at 0034000e [79721.755165] IP: [8034d147] acpi_ns_map_handle_to_node+0x14/0x1d [79721.755165] PGD 7203a067 PUD 0 [79721.755165] Oops: [1] SMP [79721.755165] CPU 1 [79721.755165] Modules linked in: usb_storage i915 drm rfcomm l2cap bluetooth fuse arc4 ecb crypto_blkcipher ehci_hcd uhci_hcd e1000e snd_hda_intel intel_agp thinkpad_acpi [last unloaded: cfg80211] [79721.755165] Pid: 69, comm: kacpi_notify Not tainted 2.6.24-git9 #4 [79721.755165] RIP: 0010:[8034d147] [8034d147] acpi_ns_map_handle_to_node+0x14/0x1d [79721.755165] RSP: 0018:81007d197d28 EFLAGS: 00010246 [79721.755165] RAX: RBX: RCX: [79721.755165] RDX: 00017567 RSI: 0012c0d0 RDI: 00340006 [79721.755165] RBP: R08: 810003c0 R09: [79721.755165] R10: 0002 R11: 0001 R12: 00340006 [79721.755165] R13: R14: 81007d197d68 R15: 81007d197d70 [79721.755165] FS: () GS:81007d00e380() knlGS: [79721.755165] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b [79721.755165] CR2: 0034000e CR3: 7200a000 CR4: 06a0 [79721.755165] DR0: DR1: DR2: [79721.755165] DR3: DR6: 0ff0 DR7: 0400 [79721.755165] Process kacpi_notify (pid: 69, threadinfo 81007d196000, task 81007d18ef20) [79721.755165] Stack: 8034e19f 8100519e8800 81007d197de0 0001 [79721.755165] 0001 80357d3d 81007d02cdc0 [79721.755165] 00340006 8058cbaa [79721.755165] Call Trace: [79721.755165] [8034e19f] acpi_get_next_object+0x3b/0x99 [79721.755165] [80357d3d] acpi_bus_trim+0x57/0x109 [79721.755165] [8035b28b] hotplug_dock_devices+0x97/0x117 [79721.755166] [8035b3a9] handle_eject_request+0x4e/0xd3 [79721.755166] [8033e04a] acpi_os_execute_notify+0x0/0x2c [79721.755166] [80356088] acpi_bus_get_device+0x1d/0x2e [79721.755166] [803560b0] acpi_bus_notify+0x17/0x4c [79721.755166] [8033e04a] acpi_os_execute_notify+0x0/0x2c [79721.755166] [80343a1d] acpi_ev_notify_dispatch+0x57/0x60 [79721.755166] [8033e06d] acpi_os_execute_notify+0x23/0x2c [79721.755166] [802460bf] run_workqueue+0xbf/0x160 [79721.755166] [80246b00] worker_thread+0x0/0x100 [79721.755166] [80246b00] worker_thread+0x0/0x100 [79721.755166] [80246b9f] worker_thread+0x9f/0x100 [79721.755166] [80249e50] autoremove_wake_function+0x0/0x30 [79721.755166] [80246b00] worker_thread+0x0/0x100 [79721.755166] [80246b00] worker_thread+0x0/0x100 [79721.755166] [80249a4b] kthread+0x4b/0x80 [79721.755166] [8020d128] child_rip+0xa/0x12 [79721.755166] [80249a00] kthread+0x0/0x80 [79721.755166] [8020d11e] child_rip+0x0/0x12 [79721.755166] [79721.755166] [79721.755166] Code: 00 c3 49 ff c1 48 83 c6 04 41 ff c8 45 85 c0 75 a8 31 c0 c6 06 00 c3 48 8d 47 ff 48 83 f8 fd 76 08 48 8b 05 dc 49 39 00 c3 31 c0 80 7f 08 0f 48 0f 44 c7 c3 48 89 f8 c3 31 c0 48 85 ff 74 0d f6 [79721.755166] RIP [8034d147] acpi_ns_map_handle_to_node+0x14/0x1d [79721.755166] RSP 81007d197d28 [79721.755166] CR2: 0034000e [79721.755166] ---[ end trace 05a1f30122eb8809 ]--- - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-git9 ACPI oops - regression
On Friday 01 February 2008 09:29, Rafael J. Wysocki wrote: [Relevant CCs added.] On Friday, 1 of February 2008, Lukas Hejtmanek wrote: Hello, I encountered oops on my laptop Lenovo T61 and dock. If I press undock on the dock, I got the following oops: this worked in 2.6.24? You are running the dock driver in both cases? Assuming yes... Since the dock driver itself hasn't changed, nor has the ACPI core, something in the framwork changed Is this reproducible? If yes, please open a bugzilla entry here: http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI Component = Config-hotplug and attach the output from acpidump thanks, -Len [79721.755165] BUG: unable to handle kernel paging request at 0034000e [79721.755165] IP: [8034d147] acpi_ns_map_handle_to_node+0x14/0x1d [79721.755165] PGD 7203a067 PUD 0 [79721.755165] Oops: [1] SMP [79721.755165] CPU 1 [79721.755165] Modules linked in: usb_storage i915 drm rfcomm l2cap bluetooth fuse arc4 ecb crypto_blkcipher ehci_hcd uhci_hcd e1000e snd_hda_intel intel_agp thinkpad_acpi [last unloaded: cfg80211] [79721.755165] Pid: 69, comm: kacpi_notify Not tainted 2.6.24-git9 #4 [79721.755165] RIP: 0010:[8034d147] [8034d147] acpi_ns_map_handle_to_node+0x14/0x1d [79721.755165] RSP: 0018:81007d197d28 EFLAGS: 00010246 [79721.755165] RAX: RBX: RCX: [79721.755165] RDX: 00017567 RSI: 0012c0d0 RDI: 00340006 [79721.755165] RBP: R08: 810003c0 R09: [79721.755165] R10: 0002 R11: 0001 R12: 00340006 [79721.755165] R13: R14: 81007d197d68 R15: 81007d197d70 [79721.755165] FS: () GS:81007d00e380() knlGS: [79721.755165] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b [79721.755165] CR2: 0034000e CR3: 7200a000 CR4: 06a0 [79721.755165] DR0: DR1: DR2: [79721.755165] DR3: DR6: 0ff0 DR7: 0400 [79721.755165] Process kacpi_notify (pid: 69, threadinfo 81007d196000, task 81007d18ef20) [79721.755165] Stack: 8034e19f 8100519e8800 81007d197de0 0001 [79721.755165] 0001 80357d3d 81007d02cdc0 [79721.755165] 00340006 8058cbaa [79721.755165] Call Trace: [79721.755165] [8034e19f] acpi_get_next_object+0x3b/0x99 [79721.755165] [80357d3d] acpi_bus_trim+0x57/0x109 [79721.755165] [8035b28b] hotplug_dock_devices+0x97/0x117 [79721.755166] [8035b3a9] handle_eject_request+0x4e/0xd3 [79721.755166] [8033e04a] acpi_os_execute_notify+0x0/0x2c [79721.755166] [80356088] acpi_bus_get_device+0x1d/0x2e [79721.755166] [803560b0] acpi_bus_notify+0x17/0x4c [79721.755166] [8033e04a] acpi_os_execute_notify+0x0/0x2c [79721.755166] [80343a1d] acpi_ev_notify_dispatch+0x57/0x60 [79721.755166] [8033e06d] acpi_os_execute_notify+0x23/0x2c [79721.755166] [802460bf] run_workqueue+0xbf/0x160 [79721.755166] [80246b00] worker_thread+0x0/0x100 [79721.755166] [80246b00] worker_thread+0x0/0x100 [79721.755166] [80246b9f] worker_thread+0x9f/0x100 [79721.755166] [80249e50] autoremove_wake_function+0x0/0x30 [79721.755166] [80246b00] worker_thread+0x0/0x100 [79721.755166] [80246b00] worker_thread+0x0/0x100 [79721.755166] [80249a4b] kthread+0x4b/0x80 [79721.755166] [8020d128] child_rip+0xa/0x12 [79721.755166] [80249a00] kthread+0x0/0x80 [79721.755166] [8020d11e] child_rip+0x0/0x12 [79721.755166] [79721.755166] [79721.755166] Code: 00 c3 49 ff c1 48 83 c6 04 41 ff c8 45 85 c0 75 a8 31 c0 c6 06 00 c3 48 8d 47 ff 48 83 f8 fd 76 08 48 8b 05 dc 49 39 00 c3 31 c0 80 7f 08 0f 48 0f 44 c7 c3 48 89 f8 c3 31 c0 48 85 ff 74 0d f6 [79721.755166] RIP [8034d147] acpi_ns_map_handle_to_node+0x14/0x1d [79721.755166] RSP 81007d197d28 [79721.755166] CR2: 0034000e [79721.755166] ---[ end trace 05a1f30122eb8809 ]--- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-git9 ACPI oops - regression
On Fri, Feb 01, 2008 at 12:07:03PM -0500, Len Brown wrote: this worked in 2.6.24? At least in 2.6.24-rc8 seemed to be OK, for the first time, I encountered the bug in 2.6.24-git4. 2.6.24-git6 seemed to be OK. 2.6.24-git9 is not. You are running the dock driver in both cases? I use thinkpad acpi module, ACPI_DOCK is always built in. Is this reproducible? In 2.6.24-git4, it was 100% reproducible - just pressing undock button on the dock and the oops has been generated. In 2.6.24-git9, I do not know, whether it is reproducible or not. And as I'm ill and my dock is in work, I'm not sure when I be ready to test it again. If yes, please open a bugzilla entry here: http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI Component = Config-hotplug and attach the output from acpidump do you need just acpidump as is or should I do acpidump when docked? -- Lukáš Hejtmánek - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCH] suspend patches for 2.6.25-rc0
Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git suspend This will update the files shown below. thanks! -Len ps. individual patches are available on linux-acpi@vger.kernel.org and a consolidated plain patch is available here: ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/suspend/2.6.24/acpi-suspend-20070126-2.6.24.diff.gz Documentation/kernel-parameters.txt|5 Documentation/power/basic-pm-debugging.txt | 216 - Documentation/power/devices.txt| 49 --- Documentation/power/drivers-testing.txt| 30 +- Documentation/power/notifiers.txt |8 Documentation/power/userland-swsusp.txt| 82 ++ arch/arm/Kconfig |3 arch/arm/mach-at91/pm.c| 17 + arch/blackfin/Kconfig |4 arch/frv/Kconfig |5 arch/mips/Kconfig |4 arch/powerpc/Kconfig | 22 + arch/powerpc/platforms/52xx/lite5200_pm.c | 10 arch/sh/Kconfig|4 arch/x86/Kconfig |8 arch/x86/kernel/suspend_64.c |8 arch/x86/mm/init_32.c | 10 drivers/acpi/hardware/hwsleep.c| 79 -- drivers/acpi/sleep/main.c | 129 -- drivers/acpi/sleep/sleep.h |2 drivers/base/power/Makefile|2 include/acpi/acpixf.h |2 include/linux/Kbuild |1 include/linux/notifier.h |2 include/linux/suspend.h| 56 ++-- include/linux/suspend_ioctls.h | 32 ++ kernel/power/Kconfig | 65 ++--- kernel/power/disk.c| 204 kernel/power/main.c| 171 +++-- kernel/power/power.h | 90 --- kernel/power/snapshot.c| 31 +- kernel/power/swap.c| 33 +- kernel/power/swsusp.c | 48 --- kernel/power/user.c| 109 ++-- 34 files changed, 1034 insertions(+), 507 deletions(-) through these commits: Adrian Bunk (1): Hibernation: Move function prototypes to header Alan Stern (2): Hibernation: Add PM_RESTORE_PREPARE and PM_POST_RESTORE notifiers (rev. 2) PM: Convert PM notifiers to out-of-line code Borislav Petkov (1): Suspend: Clean up suspend_64.c David Brownell (1): PM: Remove obsolete /sys/devices/.../power/state docs Johannes Berg (5): PM: Make PM_TRACE more architecture independent Hibernation: Clean up Kconfig (V2) Suspend: Clean up Kconfig (V2) Suspend: Add config option to disable the freezer if architecture wants that Suspend: Invoke suspend notifications after console switch Rafael J. Wysocki (27): Hibernation: Introduce SNAPSHOT_GET_IMAGE_SIZE ioctl Hibernation: Rework platform support ioctls (rev. 2) Hibernation: Mark SNAPSHOT_SET_SWAP_FILE ioctl as deprecated (rev. 2) Hibernation: Correct definitions of some ioctls (rev. 2) Hibernation: Introduce exportable suspend ioctls header (rev. 2) ACPI: Fix mismerge in acpi_hibernation_finish Suspend: Testing facility (rev. 2) suspend: build fix responding to 2.6.25 kset change Hibernation: New testing facility (rev. 2) PM: Suspend/hibernation debug documentation update (rev. 2) Suspend: Fix compilation warning for CONFIG_SUSPEND unset Hibernation: Move low level resume to disk.c Suspend: Fix comment in main.c Hibernation: Fix comment in disk.c Hibernation: Remove unnecessary variable declaration Suspend: Use common prefix in messages Hibernation: Update messages suspend: fix ia64 allmodconfig build Suspend: Introduce begin() and end() callbacks ACPI: Separate invocations of _GTS and _BFS from _PTS and _WAK ACPI: Separate disabling of GPEs from _PTS ACPI suspend: Call _PTS before suspending devices Hibernation: Introduce begin() and end() callbacks ACPI hibernation: Call _PTS before suspending devices ACPI: Print message before calling _PTS Hibernation: Invoke suspend notifications after console switch suspend: cleanup reference to swsusp_pg_dir[] Shaohua Li (1): ACPI: clear GPE earily in resume to avoid warning with this log: commit a01da01d819ceb4c3f63d2aa7e1321c6a5e53fd8 Author: Rafael J. Wysocki [EMAIL PROTECTED] Date: Fri Feb 1 15:28:16 2008 +0100 suspend: cleanup reference to swsusp_pg_dir[] swsusp_pg_dir[] is used for suspend, but not for hibernation. clean-up the ifdefs which worked by accident, while implying the opposite. Delete the __nosavedata, which also implied the
[patch 20/27] ACPICA: fix acpi-cpufreq boot crash due to _PSD return-by-reference
2.6.22-stable review patch. If anyone has any objections, please let us
know.
--
From: Bob Moore [EMAIL PROTECTED]
patch 152c300d007c70c4a1847dad39ecdaba22e7d457 in mainline.
Changed resolution of named references in packages
Fixed a problem with the Package operator where all named
references were created as object references and left otherwise
unresolved. According to the ACPI specification, a Package can
only contain Data Objects or references to control methods. The
implication is that named references to Data Objects (Integer,
Buffer, String, Package, BufferField, Field) should be resolved
immediately upon package creation. This is the approach taken
with this change. References to all other named objects (Methods,
Devices, Scopes, etc.) are all now properly created as reference objects.
http://bugzilla.kernel.org/show_bug.cgi?id=5328
http://bugzilla.kernel.org/show_bug.cgi?id=9429
Signed-off-by: Bob Moore [EMAIL PROTECTED]
Signed-off-by: Len Brown [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
drivers/acpi/dispatcher/dsobject.c | 91 ++---
1 file changed, 85 insertions(+), 6 deletions(-)
--- a/drivers/acpi/dispatcher/dsobject.c
+++ b/drivers/acpi/dispatcher/dsobject.c
@@ -137,6 +137,71 @@ acpi_ds_build_internal_object(struct acp
return_ACPI_STATUS(status);
}
}
+
+ /* Special object resolution for elements of a package */
+
+ if ((op-common.parent-common.aml_opcode == AML_PACKAGE_OP) ||
+ (op-common.parent-common.aml_opcode ==
+AML_VAR_PACKAGE_OP)) {
+ /*
+* Attempt to resolve the node to a value before we
insert it into
+* the package. If this is a reference to a common data
type,
+* resolve it immediately. According to the ACPI spec,
package
+* elements can only be data objects or method
references.
+* Attempt to resolve to an Integer, Buffer, String or
Package.
+* If cannot, return the named reference (for things
like Devices,
+* Methods, etc.) Buffer Fields and Fields will resolve
to simple
+* objects (int/buf/str/pkg).
+*
+* NOTE: References to things like Devices, Methods,
Mutexes, etc.
+* will remain as named references. This behavior is
not described
+* in the ACPI spec, but it appears to be an oversight.
+*/
+ obj_desc = (union acpi_operand_object *)op-common.node;
+
+ status =
+ acpi_ex_resolve_node_to_value(ACPI_CAST_INDIRECT_PTR
+ (struct
+ acpi_namespace_node,
+ obj_desc),
+ walk_state);
+ if (ACPI_FAILURE(status)) {
+ return_ACPI_STATUS(status);
+ }
+
+ switch (op-common.node-type) {
+ /*
+* For these types, we need the actual node,
not the subobject.
+* However, the subobject got an extra
reference count above.
+*/
+ case ACPI_TYPE_MUTEX:
+ case ACPI_TYPE_METHOD:
+ case ACPI_TYPE_POWER:
+ case ACPI_TYPE_PROCESSOR:
+ case ACPI_TYPE_EVENT:
+ case ACPI_TYPE_REGION:
+ case ACPI_TYPE_DEVICE:
+ case ACPI_TYPE_THERMAL:
+
+ obj_desc =
+ (union acpi_operand_object *)op-common.
+ node;
+ break;
+
+ default:
+ break;
+ }
+
+ /*
+* If above resolved to an operand object, we are done.
Otherwise,
+* we have a NS node, we must create the package entry
as a named
+* reference.
+*/
+ if (ACPI_GET_DESCRIPTOR_TYPE(obj_desc) !=
+ ACPI_DESC_TYPE_NAMED) {
+ goto exit;
+ }
+ }
}
/* Create and init a new internal ACPI object */
@@ -156,6 +221,7 @@ acpi_ds_build_internal_object(struct acp
Re: [ibm-acpi-devel] [GIT PATCH] thinkpad-acpi patches for 2.6.25 (replaces batch 1)
On Friday 25 January 2008 14:20, Henrique de Moraes Holschuh wrote: Len, Given that there are four cleanup patches in the batch, I didn't even attempt to bother with checkpatch on anything before the some checkpatch fluff patch. There are, for example, no tab/space problems in the final thinkpad_acpi.c file. After the entire patchset is applied, there are still a few lines over 80 chars, but that's because they are MUCH more readable the way they are in that particular hunk of code. The braces checkpatch will complain about in the final thinkpad_acpi.c file are there for good reasons. They are in points of the code where I expect a maintenance addition of one or two lines could happen, and that means any such patches would be a lot cleaner. That warning is just weird, anyway. There will be also an error about a macro needing do - while. Well, that one *does not* need it, and it is never used as a function. So, please apply the entire set and check the final thinkpad_acpi.c file with checkpatch --file... It is in *much* better state than what you got with that checkpatch run: 1 error and 12 warnings, which are all explained above. Patches after the cleanups are checkpatch-clean (except for the details explained above). applied. thanks Henrique. -Len - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Rationalise ACPI backlight implementation
Applied.
thanks,
-Len
On Tuesday 25 December 2007 21:03, Matthew Garrett wrote:
The sysfs backlight class provides no mechanism for querying the
acceptable brightness for a backlight. The ACPI spec states that values
are only valid if they are reported as available by the firmware. Since
we can't provide that information to userspace, instead collapse the
range to the number of actual values that can be set.
Signed-off-by: Matthew Garrett [EMAIL PROTECTED]
---
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 521645e..12b2adb 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -296,18 +296,26 @@ static int acpi_video_device_set_state(struct
acpi_video_device *device, int sta
static int acpi_video_get_brightness(struct backlight_device *bd)
{
unsigned long cur_level;
+ int i;
struct acpi_video_device *vd =
(struct acpi_video_device *)bl_get_data(bd);
acpi_video_device_lcd_get_level_current(vd, cur_level);
- return (int) cur_level;
+ for (i=2; ivd-brightness-count; i++) {
+ if (vd-brightness-levels[i] == cur_level)
+ /* The first two entries are special - see page 575
+of the ACPI spec 3.0 */
+ return i-2;
+ }
+ return 0;
}
static int acpi_video_set_brightness(struct backlight_device *bd)
{
- int request_level = bd-props.brightness;
+ int request_level = bd-props.brightness+2;
struct acpi_video_device *vd =
(struct acpi_video_device *)bl_get_data(bd);
- acpi_video_device_lcd_set_level(vd, request_level);
+ acpi_video_device_lcd_set_level(vd,
+ vd-brightness-levels[request_level]);
return 0;
}
@@ -656,7 +664,6 @@ static void acpi_video_device_find_cap(struct
acpi_video_device *device)
kfree(obj);
if (device-cap._BCL device-cap._BCM device-cap._BQC
max_level 0){
- unsigned long tmp;
static int count = 0;
char *name;
name = kzalloc(MAX_NAME_LEN, GFP_KERNEL);
@@ -664,11 +671,10 @@ static void acpi_video_device_find_cap(struct
acpi_video_device *device)
return;
sprintf(name, acpi_video%d, count++);
- acpi_video_device_lcd_get_level_current(device, tmp);
device-backlight = backlight_device_register(name,
NULL, device, acpi_backlight_ops);
- device-backlight-props.max_brightness = max_level;
- device-backlight-props.brightness = (int)tmp;
+ device-backlight-props.max_brightness =
device-brightness-count-3;
+ device-backlight-props.brightness =
acpi_video_get_brightness(device-backlight);
backlight_update_status(device-backlight);
kfree(name);
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Rationalise ACPI backlight implementation
On Monday 28 January 2008 00:10, Andrew Morton wrote: On Mon, 28 Jan 2008 01:25:50 + Matthew Garrett [EMAIL PROTECTED] wrote: On Sat, Jan 26, 2008 at 10:00:45PM -0800, Andrew Morton wrote: - Create a new /sys node with a new name which has the new semantics. The semantics are the same as they always have been - values between 0 and max_brightness are valid values. If you've made assumptions about what max_brightness is, then that's a bug in the userspace application rather than a change in the semantics of the interface. WTH? My (utterly comedic chase-crap-around-the-tree) brightness script was: ( 0 sh -c echo $1 /proc/acpi/sony/brightness 0 sh -c echo $1 /proc/acpi/sony/brightness_default 0 sh -c echo $1 /sys/class/backlight/sony/brightness 0 sh -c echo $1 /sys/class/backlight/thinkpad_screen/brightness ) 2/dev/null And yes, I had an rc.local command which assumed that 7 (later 8) is max brightness. You cannot seriously tell me that if we are to change this range from 0-8 up to 0-100 then this is not a backwards-incompatible change in semantics. My /sys/class/backlight/ directory is presently empty. Rather than trying to find out why, I think I'll just collapse in laughter. Guys, sort it out, please. I think that Matthew got it right. The generic API is unchanged, brightness goes from 0 to max_brighness. What he did was repair systems that use the acpi video driver (which none of akpm's examples above do) such that the generic API works for that case the same as it does with all other video drivers. Andrew, You might check if CONFIG_ACPI_VIDEO=m is set and you can load the video module. While the sony may be non-standard and not load, your thinkpad may work. thanks, -Len - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ACPI: video: introduce new flag for enabling/disabling ACPI video actions upon brightness switch notifications
Applied.
thanks,
-Len
On Friday 25 January 2008 01:47, Zhang Rui wrote:
From: Zhang Rui [EMAIL PROTECTED]
Introduce new module parameter for brightness control.
brightness_switch_enabled is set by default which means
nothing changes upon brightness switch events.
When brightness_switch_enabled is cleared via
echo 0 /sys/module/video/parameters/brightness_switch_enabled,
ACPI will not try to change the brightness level any more.
Either X will take charge of this or users can change the brightness level
by poking /sys/class/backlight/acpi_videoX/...
Signed-off-by: Zhang Rui [EMAIL PROTECTED]
---
drivers/acpi/video.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
Index: linux-2.6/drivers/acpi/video.c
===
--- linux-2.6.orig/drivers/acpi/video.c
+++ linux-2.6/drivers/acpi/video.c
@@ -72,6 +72,9 @@ MODULE_AUTHOR(Bruno Ducrot);
MODULE_DESCRIPTION(ACPI Video Driver);
MODULE_LICENSE(GPL);
+static int brightness_switch_enabled = 1;
+module_param(brightness_switch_enabled, bool, 0644);
+
static int acpi_video_bus_add(struct acpi_device *device);
static int acpi_video_bus_remove(struct acpi_device *device, int type);
@@ -1850,27 +1853,32 @@ static void acpi_video_device_notify(acp
switch (event) {
case ACPI_VIDEO_NOTIFY_CYCLE_BRIGHTNESS:/* Cycle brightness */
- acpi_video_switch_brightness(video_device, event);
+ if (brightness_switch_enabled)
+ acpi_video_switch_brightness(video_device, event);
acpi_bus_generate_proc_event(device, event, 0);
keycode = KEY_BRIGHTNESS_CYCLE;
break;
case ACPI_VIDEO_NOTIFY_INC_BRIGHTNESS: /* Increase brightness */
- acpi_video_switch_brightness(video_device, event);
+ if (brightness_switch_enabled)
+ acpi_video_switch_brightness(video_device, event);
acpi_bus_generate_proc_event(device, event, 0);
keycode = KEY_BRIGHTNESSUP;
break;
case ACPI_VIDEO_NOTIFY_DEC_BRIGHTNESS: /* Decrease brightness */
- acpi_video_switch_brightness(video_device, event);
+ if (brightness_switch_enabled)
+ acpi_video_switch_brightness(video_device, event);
acpi_bus_generate_proc_event(device, event, 0);
keycode = KEY_BRIGHTNESSDOWN;
break;
case ACPI_VIDEO_NOTIFY_ZERO_BRIGHTNESS: /* zero brightnesss */
- acpi_video_switch_brightness(video_device, event);
+ if (brightness_switch_enabled)
+ acpi_video_switch_brightness(video_device, event);
acpi_bus_generate_proc_event(device, event, 0);
keycode = KEY_BRIGHTNESS_ZERO;
break;
case ACPI_VIDEO_NOTIFY_DISPLAY_OFF: /* display device off */
- acpi_video_switch_brightness(video_device, event);
+ if (brightness_switch_enabled)
+ acpi_video_switch_brightness(video_device, event);
acpi_bus_generate_proc_event(device, event, 0);
keycode = KEY_DISPLAY_OFF;
break;
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ACPI: video: prevent ACPI video actions upon display switch notifications
Applied.
thanks,
-Len
On Friday 25 January 2008 01:47, Zhang Rui wrote:
From: Zhang Rui [EMAIL PROTECTED]
Display switching via ACPI control methods are known to work on none
platform AFAIK.
And graphics people want to control the display switching all by themselves.
Prevent ACPI from handling display switch hotkey events in this patch.
Signed-off-by: Zhang Rui [EMAIL PROTECTED]
---
drivers/acpi/video.c | 63
---
1 file changed, 63 deletions(-)
Index: linux-2.6/drivers/acpi/video.c
===
--- linux-2.6.orig/drivers/acpi/video.c
+++ linux-2.6/drivers/acpi/video.c
@@ -276,7 +276,6 @@ static void acpi_video_device_rebind(str
static void acpi_video_device_bind(struct acpi_video_bus *video,
struct acpi_video_device *device);
static int acpi_video_device_enumerate(struct acpi_video_bus *video);
-static int acpi_video_switch_output(struct acpi_video_bus *video, int event);
static int acpi_video_device_lcd_set_level(struct acpi_video_device *device,
int level);
static int acpi_video_device_lcd_get_level_current(
@@ -1583,64 +1582,6 @@ static int acpi_video_device_enumerate(s
return status;
}
-/*
- * Arg:
- * video : video bus device
- * event : notify event
- *
- * Return:
- *0 : error
- *
- * 1. Find out the current active output device.
- * 2. Identify the next output device to switch to.
- * 3. call _DSS to do actual switch.
- */
-
-static int acpi_video_switch_output(struct acpi_video_bus *video, int event)
-{
- struct list_head *node;
- struct acpi_video_device *dev = NULL;
- struct acpi_video_device *dev_next = NULL;
- struct acpi_video_device *dev_prev = NULL;
- unsigned long state;
- int status = 0;
-
- mutex_lock(video-device_list_lock);
-
- list_for_each(node, video-video_device_list) {
- dev = container_of(node, struct acpi_video_device, entry);
- status = acpi_video_device_get_state(dev, state);
- if (state 0x2) {
- dev_next = container_of(node-next,
- struct acpi_video_device, entry);
- dev_prev = container_of(node-prev,
- struct acpi_video_device, entry);
- goto out;
- }
- }
-
- dev_next = container_of(node-next, struct acpi_video_device, entry);
- dev_prev = container_of(node-prev, struct acpi_video_device, entry);
-
- out:
- mutex_unlock(video-device_list_lock);
-
- switch (event) {
- case ACPI_VIDEO_NOTIFY_CYCLE:
- case ACPI_VIDEO_NOTIFY_NEXT_OUTPUT:
- acpi_video_device_set_state(dev, 0);
- acpi_video_device_set_state(dev_next, 0x8001);
- break;
- case ACPI_VIDEO_NOTIFY_PREV_OUTPUT:
- acpi_video_device_set_state(dev, 0);
- acpi_video_device_set_state(dev_prev, 0x8001);
- default:
- break;
- }
-
- return status;
-}
-
static int
acpi_video_get_next_level(struct acpi_video_device *device,
u32 level_current, u32 event)
@@ -1800,23 +1741,19 @@ static void acpi_video_bus_notify(acpi_h
* connector. */
acpi_video_device_enumerate(video);
acpi_video_device_rebind(video);
- acpi_video_switch_output(video, event);
acpi_bus_generate_proc_event(device, event, 0);
keycode = KEY_SWITCHVIDEOMODE;
break;
case ACPI_VIDEO_NOTIFY_CYCLE: /* Cycle Display output hotkey pressed.
*/
- acpi_video_switch_output(video, event);
acpi_bus_generate_proc_event(device, event, 0);
keycode = KEY_SWITCHVIDEOMODE;
break;
case ACPI_VIDEO_NOTIFY_NEXT_OUTPUT: /* Next Display output hotkey
pressed. */
- acpi_video_switch_output(video, event);
acpi_bus_generate_proc_event(device, event, 0);
keycode = KEY_VIDEO_NEXT;
break;
case ACPI_VIDEO_NOTIFY_PREV_OUTPUT: /* previous Display output
hotkey pressed. */
- acpi_video_switch_output(video, event);
acpi_bus_generate_proc_event(device, event, 0);
keycode = KEY_VIDEO_PREV;
break;
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] ACPI: create ACPI notifier chain
Applied.
thanks,
-Len
On Friday 25 January 2008 01:48, Zhang Rui wrote:
From: Zhang Rui [EMAIL PROTECTED]
This patch is needed by the kernel mode graphics drivers.
Create an ACPI notifier chain so that they can get
notified upon hotkey events.
Signed-off-by: Zhang Rui [EMAIL PROTECTED]
---
drivers/acpi/event.c| 28
include/acpi/acpi_bus.h |3 +++
2 files changed, 31 insertions(+)
Index: linux-2.6/drivers/acpi/event.c
===
--- linux-2.6.orig/drivers/acpi/event.c
+++ linux-2.6/drivers/acpi/event.c
@@ -109,6 +109,34 @@ static const struct file_operations acpi
};
#endif /* CONFIG_ACPI_PROC_EVENT */
+/* ACPI notifier chain */
+BLOCKING_NOTIFIER_HEAD(acpi_chain_head);
+
+int acpi_notifier_call_chain(struct acpi_device *dev, u32 type, u32 data)
+{
+ struct acpi_bus_event event;
+
+ strcpy(event.device_class, dev-pnp.device_class);
+ strcpy(event.bus_id, dev-pnp.bus_id);
+ event.type = type;
+ event.data = data;
+ return (blocking_notifier_call_chain(acpi_chain_head, 0, (void
*)event)
+== NOTIFY_BAD) ? -EINVAL : 0;
+}
+EXPORT_SYMBOL(acpi_notifier_call_chain);
+
+int register_acpi_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_register(acpi_chain_head, nb);
+}
+EXPORT_SYMBOL(register_acpi_notifier);
+
+int unregister_acpi_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_unregister(acpi_chain_head, nb);
+}
+EXPORT_SYMBOL(unregister_acpi_notifier);
+
#ifdef CONFIG_NET
static unsigned int acpi_event_seqnum;
struct acpi_genl_event {
Index: linux-2.6/include/acpi/acpi_bus.h
===
--- linux-2.6.orig/include/acpi/acpi_bus.h
+++ linux-2.6/include/acpi/acpi_bus.h
@@ -320,6 +320,9 @@ struct acpi_bus_event {
extern struct kset acpi_subsys;
extern int acpi_bus_generate_netlink_event(const char*, const char*, u8,
int);
+extern int acpi_notifier_call_chain(struct acpi_device *, u32, u32);
+extern int register_acpi_notifier(struct notifier_block *);
+extern int unregister_acpi_notifier(struct notifier_block *);
/*
* External Functions
*/
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ACPI: video: call ACPI notifier chain for ACPI video notifications
Applied. thanks, -Len On Friday 25 January 2008 01:48, Zhang Rui wrote: From: Zhang Rui [EMAIL PROTECTED] Call notifier chain for display/brightness switch events. The kernel mode graphics driver is interested in this. Sign-off-by: Zhang Rui [EMAIL PROTECTED] --- drivers/acpi/video.c |2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6/drivers/acpi/video.c === --- linux-2.6.orig/drivers/acpi/video.c +++ linux-2.6/drivers/acpi/video.c @@ -1765,6 +1765,7 @@ static void acpi_video_bus_notify(acpi_h break; } + acpi_notifier_call_chain(device, event, 0); input_report_key(input, keycode, 1); input_sync(input); input_report_key(input, keycode, 0); @@ -1826,6 +1827,7 @@ static void acpi_video_device_notify(acp break; } + acpi_notifier_call_chain(device, event, 0); input_report_key(input, keycode, 1); input_sync(input); input_report_key(input, keycode, 0); - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/10] generic thermal management
series applied to acpi-test. thanks, -Len On Thursday 17 January 2008 02:50, Zhang Rui wrote: Hi, all, This patch series introduces a new generic thermal sysfs driver which provides a set of interfaces for thermal zone devices (sensors) and thermal cooling devices (fan, processor...) to register with the thermal management solution and to be a part of it. And it also includes the implementation for ACPI thermal zone. Standard sysfs I/F should be available for all ACPI thermal zones with this patch series applied. Patch 01 creates the new generic thermal sysfs driver. It defines two kinds of devices, thermal zone device and thermal cooling device. A thermal zone device usually contains a sensor to monitor the temperature, several trip points and a bunch of cooling devices associated with them. A thermal cooling device is a device that can be throttled to cool the system. The generic thermal sysfs driver creates the standard sysfs I/F for any registered thermal zone and thermal cooling device. And binds the cooling devices to thermal zones if possible. Patch 02 registers ACPI thermal zone as thermal zone device. Patch 03 is a fix of violations of ACPI spec in ACPI thermal driver. Patch 04 registers ACPI Fan as thermal cooling device. Patch 05 registers ACPI Processor as thermal cooling device. Patch 06 registers ACPI Video LCD as thermal cooling device. Because throttling the backlight of LCD can cool the system as well. Patch 09 creates a new platform specific driver, intel_menlow. which is the thermal enhancement driver for intel menlow platform. It programs the sensor of each thermal zone and registers the intel memory controller (hardware id INT0002) as thermal cooling device. Patch 07 08 and 10 are minor fixes, please refer to the changelog of each patch. I've tested them and they work well on several systems. I'd like to get some feedbacks from the list. Any comments are appreciated. :) Thanks, Rui -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] ACPI: Battery hotplug support
Series applied to acpi-test thanks, -Len On Wednesday 16 January 2008 20:19, Zhang Rui wrote: Hi, all, This patch series is for battery hotplug support. Please refer to http://bugzilla.kernel.org/show_bug.cgi?id=2884 Patch 01 flushes kacpi_notify_wq before removing the notify handler as well as the kacpid_wq. Patch 02 adds a new acpi execute type, OSL_DEVICE_HOTPLUG_HANDLER, This is used for the device hotplug notify handler which will be queued in keventd_wq so that it can flush the kacpi_notify_wq. Patch 03 support battery hotplug in the global system-level notify handler acpi_bus_notify. Patch 04 fix the deadlock when pokiing the eject sysfs attribute which is used to eject a device in user space. I've tested this patch set on my t43 laptop and it works well. Any comment is appreciated. :) Thanks, Rui - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Override DSDT and SSDTs via initramfs
On Friday 01 February 2008 04:53, Thomas Renninger wrote: That gives you complete and total control over what AML gets run I doubt that. You said there can be any number of SSDTs. If you know what you are doing..., but how do you explain someone in a bug that he has to collect all SSDTs (some via acpidump --addr xy) open an editor, paste them into the DSDT and so on... Dynamic SSDT's are loaded from OpRegions by address. If you want to change the AML in those opregions, you have to acquire it with acpidump --addr xy. That is true no mater what override scheme you're using. However, if you don't want to modify the dynamic SSDT, then it does not have to be dumped -- it will continue to be accessed via Load() of the opregion; and it is totally unrelated to a DSDT or a DSDT+static-SSDT override. I am doubtful that SSDT override support past what we have already justifies its own complexity. -Len - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
