Hi Carlos, Thanks for your persistence. I've included this patch series to the acpi-test branch.
I think the indication of success of this effort will be other people writing drivers to do useful things with the WMI hooks you are exposing. So we certainly want to get the base driver out there sooner to support that. I don't know if it would be better to ship a prototype sysfs user interface in the hopes it encourages adopters and get feedback to make it better, or to bake it more out of tree in the hopes of shipping something more final in the first shot. I'm inclined to ship an EXPERIMENTAL API because the more eyes on it sooner the better. One option would be to have the sysfs I/F be a sub-config option that is default N -- indeed, you can call it a DEBUGGING or DEVELOPMENT I/F to scare people away from the the wrong impression:-) > Patch #1: (WMI - driver and in kernel interface) - Minor clean up > > Replace leftover occurences of 'x == NULL' with '!x' > > Len: For you to review and to be applied to acpi-test. > > +config ACPI_WMI > + tristate "WMI (EXPERIMENTAL)" > + depends on EXPERIMENTAL > + default m I deleted the "default m" line when i checked in this patch. So if you revise/resend this patch in the future, please do the same. > ==== > > Patch #2: (acer-wmi) - New DMI entry, mail LED detection fix, mismatch fix > > * Don't fail if we can't detect a mail LED on AMW0 systems > * Add an EC quirk for the Acer Aspire 9110 > * Fix section mismatch warnings > > Len: For you to review and to be applied to acpi-test. acer-wmi needs a MAINTAINER > > Patch #3: (tc1100-wmi) - No Change > > RFC only, needs actual testing on the hardware, and probably very broken. > Waiting on Matthew Garrett to get some free time to test this. tc1100-wmi needs a MAINTAINER > Patch #4: (WMI sysfs interface) - No Change > > RFC only (see patch #5 for reason and discussion). Adds interface under > /sys/devices/virtual/wmi > > Also adds a function to return the (virtual) device associated with a GUID for > use by other parts of the kernel that want to set a parent device. > > Len: To review (but not to apply yet, unless you want to apply patch #5 as > well) I don't understand the WMI user/kernel sysfs API. I guess i had originally expected it to live in /sys/firmware/wmi, but I see that they put dmi a subset of DMI under /sys/class/dmi, so i guess there is precident... I got my main wish, which was to have not _not_ be under some ACPI specific directory:-) > Patch #5: (WMI sysfs workaround) - No Change > > Temporary hack, needed to get patch #4 working, due to a limitation on bus_id > length (Kay Sievers is apparently working on this, ref Greg KH[1]). > > Len: > > Apparently, the necessary fixes _might_ go into 2.6.25 as well, or worst case > scenario is 2.6.26[2]. So we can either: > > 1) Hold off on patch #4 until the necessary fixes go in (this might be 2.6.25 > if we're lucky, or we end up putting off WMI sysfs support until 2.6.26) > or > > 2) Apply patch #4, and #5 on top as a temporary hack, and then revert #5 as > soon as the necessary changes go in. (For bisection purposes, #4 and #5 should > be merged if we go ahead with this). > > I don't know what would be the best solution here. #2 is the better route -- move forward using workaround, and revert the workaround when it is no longer needed. The risk is if somebody in user-space starts actually programming to 19-character GUIDS. > [1] http://lkml.org/lkml/2007/12/4/30 > [2] http://www.nabble.com/Re:-Fix-Firmware-class-name-collision-p14352966.html I loaded this driver on an HP nx6325 as well as a Lenovo T61. just for kicks i tried to dump the data attributes, but on both machines I found that some of them oops in wmi_data_read like below. thanks, -Len Feb 2 22:05:55 t61 kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 Feb 2 22:05:55 t61 kernel: IP: [<ffffffff8808bcce>] :wmi:wmi_data_read+0xc2/0xe0 Feb 2 22:05:55 t61 kernel: PGD 7bcdc067 PUD 719b9067 PMD 0 Feb 2 22:05:55 t61 kernel: Oops: 0000 [1] SMP Feb 2 22:05:55 t61 kernel: CPU 0 Feb 2 22:05:55 t61 kernel: Modules linked in: acpi_cpufreq pcmcia yenta_socket rsrc_nonstatic wmi ac battery video thermal iwl4965 mac80211 cfg80211 e1000e thinkpad_acpi backlight nvram Feb 2 22:05:55 t61 kernel: Pid: 3875, comm: cat Not tainted 2.6.24-06933-g9b85450-dirty #112 Feb 2 22:05:55 t61 kernel: RIP: 0010:[<ffffffff8808bcce>] [<ffffffff8808bcce>] :wmi:wmi_data_read+0xc2/0xe0 Feb 2 22:05:55 t61 kernel: RSP: 0018:ffff810071851e68 EFLAGS: 00010296 Feb 2 22:05:55 t61 kernel: RAX: 0000000000000000 RBX: ffff81007b4a6118 RCX: 0000000000000010 Feb 2 22:05:55 t61 kernel: RDX: 00000000ffffffcb RSI: ffff810071851d78 RDI: ffff81007b4a6d70 Feb 2 22:05:55 t61 kernel: RBP: ffff810071851ea8 R08: 0000000000001000 R09: ffff81007b83c9b0 Feb 2 22:05:55 t61 kernel: R10: ffff810071851d88 R11: 0000000000000246 R12: 0000000000001000 Feb 2 22:05:55 t61 kernel: R13: ffff81007b4a6128 R14: 0000000000000000 R15: ffffffff8808d7e0 Feb 2 22:05:55 t61 kernel: FS: 00007f7b4130d6f0(0000) GS:ffffffff80777000(0000) knlGS:0000000000000000 Feb 2 22:05:55 t61 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b Feb 2 22:05:55 t61 kernel: CR2: 0000000000000000 CR3: 00000000719b0000 CR4: 00000000000006e0 Feb 2 22:05:55 t61 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Feb 2 22:05:55 t61 kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Feb 2 22:05:55 t61 kernel: Process cat (pid: 3875, threadinfo ffff810071850000, task ffff81007b45a280) Feb 2 22:05:55 t61 kernel: Stack: ffffffffffffffff 0000000000000000 0000000000000000 0000000147a52f6e Feb 2 22:05:55 t61 kernel: ffff810071851ea8 ffff81007ac61dd0 0000000000001000 00000000ffffffed Feb 2 22:05:55 t61 kernel: ffff810071851f08 ffffffff802c8b83 ffff810071851f48 0000000000abf000 Feb 2 22:05:55 t61 kernel: Call Trace: Feb 2 22:05:55 t61 kernel: [<ffffffff802c8b83>] read+0xc8/0x137 Feb 2 22:05:55 t61 kernel: [<ffffffff80287583>] vfs_read+0xab/0x134 Feb 2 22:05:55 t61 kernel: [<ffffffff80287948>] sys_read+0x47/0x6f Feb 2 22:05:55 t61 kernel: [<ffffffff8020b16b>] system_call_after_swapgs+0x7b/0x80 Feb 2 22:05:55 t61 kernel: Feb 2 22:05:55 t61 kernel: Feb 2 22:05:55 t61 kernel: Code: c9 4c 89 ef e8 5b fe ff ff 48 c7 c7 50 d8 08 88 e8 47 f9 4e f8 eb 10 48 8d 55 c0 41 0f b6 f4 4c 89 ef e8 f7 fc ff ff 48 8b 45 c8 <8b> 00 83 e8 02 83 f8 02 48 19 c0 48 f7 d0 48 83 e0 fb 48 83 c4 Feb 2 22:05:55 t61 kernel: RIP [<ffffffff8808bcce>] :wmi:wmi_data_read+0xc2/0xe0 Feb 2 22:05:55 t61 kernel: RSP <ffff810071851e68> Feb 2 22:05:55 t61 kernel: CR2: 0000000000000000 Feb 2 22:05:55 t61 kernel: ---[ end trace 0d56088a35d7a80e ]--- - 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
