summaryrefslogtreecommitdiffstats
path: root/drivers/acpi/wmi.c
AgeCommit message (Collapse)AuthorFilesLines
2008-11-06ACPI: struct device - replace bus_id with dev_name(), dev_set_name()Kay Sievers1-1/+1
This patch is part of a larger patch series which will remove the "char bus_id[20]" name string from struct device. The device name is managed in the kobject anyway, and without any size limitation, and just needlessly copied into "struct device". To set and read the device name dev_name(dev) and dev_set_name(dev) must be used. If your code uses static kobjects, which it shouldn't do, "const char *init_name" can be used to statically provide the name the registered device should have. At registration time, the init_name field is cleared, to enforce the use of dev_name(dev) to access the device name at a later time. We need to get rid of all occurrences of bus_id in the entire tree to be able to enable the new interface. Please apply this patch, and possibly convert any remaining remaining occurrences of bus_id. We want to submit a patch to -next, which will remove bus_id from "struct device", to find the remaining pieces to convert, and finally switch over to the new api, which will remove the 20 bytes array and does no longer have a size limitation. Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-Off-By: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Len Brown <len.brown@intel.com>
2008-10-22Merge branch 'bugfixes' into testLen Brown1-5/+5
2008-10-22ACPI: replace AE_BAD_ADDRESS exception code with AE_ERRORLin Ming1-5/+5
The AE_BAD_ADDRESS exception code is now unused in ACPICA. For linux, it's only used at wmi.c and acer-wmi.c. I checked both wmi.c and acer-wmi.c, the AE_BAD_ADDRESS exception code has no special meaning. The parent functions just call AE_SUCCESS() or AE_FAILURE() to check the return status. So it's safe to replace AE_BAD_ADDRESS with AE_ERROR. Signed-off-by Lin Ming <ming.m.lin@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-10-08ACPI: WMI: Enable event methods when registering notifiersMatthew Garrett1-2/+37
According to the ACPI-WMI spec, event blocks may provide a function call for enabling/disabling them. This patch adds support for making these calls when registering or removing notifications. Without this, my Dell firmware provides no data in the event notification. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Carlos Corbacho <carlos@strangeworlds.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
2008-08-15ACPI: WMI: Set instance for query block callsCarlos Corbacho1-1/+1
Although the necessary data structure was set up, it was never actually passed in, so data block calls have only been working by sheer chance. (On Acer laptops. the data block methods we've been calling never look at the instance value, hence acer-wmi never triggered this before). f3454ae8104efb2dbf0d08ec42c6f5d0fe9225bc brought this to light. Signed-off-by: Carlos Corbacho <carlos@strangeworlds.co.uk> Signed-off-by: Andi Kleen <ak@linux.intel.com>
2008-03-11ACPI: WMI: Clean up handling of spec violating data blocksCarlos Corbacho1-4/+6
Acer violate the ACPI-WMI spec by declaring some of their data blocks as expensive, but with no corresponding WCxx method. There is already some workaround code in to handle the initial WCxx call (we just ignore a failure here); but we need to properly check if the second, "clean up", WCxx call is actually needed or not, rather than fail simply because it isn't there. Signed-off-by: Carlos Corbacho <carlos@strangeworlds.co.uk> Signed-off-by: Len Brown <len.brown@intel.com>
2008-02-13wmi: (!x & y) strikes againAl Viro1-1/+1
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Acked-by: Carlos Corbacho <carlos@strangeworlds.co.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-11WMI: initialize wmi_blocks.list even if ACPI is disabledLinus Torvalds1-2/+2
Even if we don't want to register the WMI driver, we should initialize the wmi_blocks list to be empty, since we don't want the wmi helper functions to oops just because that basic list has not even been set up. With this, "find_guid()" will happily return "not found" rather than oopsing all over the place, and the callers will then just automatically return false or AE_NOT_FOUND as appropriate. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-05ACPI: WMI: Add ACPI-WMI mapping driverCarlos Corbacho1-0/+710
The following is an implementation of the Windows Management Instrumentation (WMI) ACPI interface mapper (PNP0C14). What it does: Parses the _WDG method and exports functions to process WMI method calls, data block query/ set commands (both based on GUID) and does basic event handling. How: WMI presents an in kernel interface here (essentially, a minimal wrapper around ACPI) (const char *guid assume the 36 character ASCII representation of a GUID - e.g. 67C3371D-95A3-4C37-BB61-DD47B491DAAB) wmi_evaluate_method(const char *guid, u8 instance, u32 method_id, const struct acpi_buffer *in, struct acpi_buffer *out) wmi_query_block(const char *guid, u8 instance, struct acpi_buffer *out) wmi_set_block(const char *guid, u38 instance, const struct acpi_buffer *in) wmi_install_notify_handler(acpi_notify_handler handler); wmi_remove_notify_handler(void); wmi_get_event_data(u32 event, struct acpi_buffer *out) wmi_has_guid(const char guid*) wmi_has_guid() is a helper function to find if a GUID exists or not on the system (a quick and easy way for WMI dependant drivers to see if the the method/ block they want exists, since GUIDs are supposed to be unique). Event handling - allow a WMI based driver to register a notifier handler for each GUID with WMI. When a notification is sent to a GUID in WMI, the handler registered with WMI is then called (it is left to the caller to ask for the WMI event data associated with the GUID, if needed). What it won't do: Unicode - The MS article[1] calls for converting between ASCII and Unicode (or vice versa) if a GUID is marked as "string". This is left up to the calling driver. Handle a MOF[1] - the WMI mapper just exports methods, data and events to userspace. MOF handling is down to userspace. Userspace interface - this will be added later. [1] http://www.microsoft.com/whdc/system/pnppwr/wmi/wmi-acpi.mspx === ChangeLog == v1 (2007-10-02): * Initial release v2 (2007-10-05): * Cleaned up code - split up super "wmi_evaluate_block" -> each external symbol now handles its own ACPI calls, rather than handing off to a "super" method (and in turn, is a lot simpler to read) * Added a find_guid() symbol - return true if a given GUID exists on the system * wmi_* functions now return type acpi_status (since they are just fancy wrappers around acpi_evaluate_object()) * Removed extra debug code v3 (2007-10-27) * More code clean up - now passes checkpatch.pl * Change data block calls - ref MS spec, method ID is not required for them, so drop it from the function parameters. * Const'ify guid in the function call parameters. * Fix _WDG buffer handling - copy the data to our own private structure. * Change WMI from tristate to bool - otherwise the external functions are not exported in linux/acpi.h if you try to build WMI as a module. * Fix more flag comparisons. * Add a maintainers entry - since I wrote this, I should take the blame for it. v4 (2007-10-30) * Add missing brace from after fixing checkpatch errors. * Rewrote event handling - allow external drivers to register with WMI to handle WMI events * Clean up flags and sanitise flag handling v5 (2007-11-03) * Add sysfs interface for userspace. Export events over netlink again. * Remove module left overs, fully convert to built-in driver. * Tweak in-kernel API to use u8 for instance, since this is what the GUID blocks use (so instance cannot be greater than u8). * Export wmi_get_event_data() for in kernel WMI drivers. v6 (2007-11-07) * Split out userspace into a different patch v7 (2007-11-20) * Fix driver to handle multiple PNP0C14 devices - store all GUIDs using the kernel's built in list functions, and just keep adding to the list every time we handle a PNP0C14 devices - GUIDs will always be unique, and WMI callers do not know or care about different devices. * Change WMI event handler registration to use its' own event handling struct; we should not pass an acpi_handle down to any WMI based drivers - they should be able to function with only the calls provided in WMI. * Update my e-mail address v8 (2007-11-28) * Convert back to a module. * Update Kconfig to default to building as a module. * Remove an erroneous printk. * Simply comments for string flag (since we now leave the handling to the caller). v9 (2007-12-07) * Add back missing MODULE_DEVICE_TABLE for autoloading * Checkpatch fixes v10 (2007-12-12) * Workaround broken GUIDs declared expensive without a WCxx method. * Minor cleanups v11 (2007-12-17) * More fixing for broken GUIDs declared expensive without a WCxx method. * Add basic EmbeddedControl region handling. v12 (2007-12-18) * Changed EC region handling code, as per Alexey's comments. v13 (2007-12-27) * Changed event handling so that we can have one event handler registered per GUID, as per Matthew Garrett's suggestion. v14 (2008-01-12) * Remove ACPI debug statements v15 (2008-02-01) * Replace two remaining 'x == NULL' type tests with '!x' v16 (2008-02-05) * Change MAINTAINERS entry, as I am not, and never have been, paid to work on WMI * Remove 'default' line from Kconfig Signed-off-by: Carlos Corbacho <carlos@strangeworlds.co.uk> CC: Matthew Garrett <mjg59@srcf.ucam.org> CC: Alexey Starikovskiy <aystarik@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>