Skip to contentSkip to conversation

ACPI: WMI: Initial attempt at WMI ACPI interface driver

RFC PATCH In review Carlos Corbacho 2 participants 2 messages Oct 4, 2007 – Oct 10, 2007 ACPI

lore
Share & tools
lore
#0 lore raw

RFC PATCH v2 1/1 ACPI: WMI: Initial attempt at WMI ACPI interface driver

The following is my own basic implementation of a Windows Management Instrumentation (WMI) ACPI interface mapper (PNP0C14).

What it does:

Parses the _WDG method and exports functions to process WMI method calls (tested with my own hacked up version of acer_acpi), and basic data block query/ set commands (WQxx and WSxx _not_ marked as "expensive") based on GUID.

i.e.

wmi_evaluate_method(const char *guid, u32 instance, u32 method_id, const struct acpi_buffer *in, struct acpi_buffer *out)

wmi_query_block(const char *guid, u32 instance, u32 method_id, struct acpi_buffer *out)

wmi_set_block(const char *guid, u32 instance, u32 method_id, const struct acpi_buffer *in)

It also provides a helper method 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).

i.e.

bool find_guid(const char guid*)

Where guid is the text encoding of the guid, e.g.:

"67C3371D-95A3-4C37-BB61-DD47B491DAAB"

What it might be able to do:

Handle reading data block GUIDs marked as "expensive" (e.g. calling WCxx with the correct arguments, before and after querying the block in question). My DSDT does not have any such marked block methods, so this is untested.

What it can't do:

Events - I've added a notify handler, but when we get a Notify() call to PNP0C14, what should happen next?

(The MS article[1] says something about "firing a WMI event", in conjunction with the data from the _WED method - would the driver be expected to send an event to proc/ netlink?).

This would also need to handle events marked as "expensive"

Unicode - The MS article calls for converting between ASCII and Unicode (or vice versa) if a GUID is marked as "string". There is also another problem in that given this specification revolves around Windows, Unicode in this context likely means UTF-16. Since Linux doesn't use this, and since this driver will only be called by other Linux drivers, it may make more sense to treat Unicode here as UTF-8 instead.

What it doesn't do:

Try to enforce any kind of MOF 'types' on the data - it just takes and returns acpi_buffer - interpretation is left to the caller.

[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

---
 drivers/acpi/Kconfig  |   10 +
 drivers/acpi/Makefile |    1 +
 drivers/acpi/wmi.c    |  480 +++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/acpi.h  |   14 ++
 4 files changed, 505 insertions(+), 0 deletions(-)
 create mode 100644 drivers/acpi/wmi.c
drivers/acpi/Kconfig +10 -0
index 9685b75..b2074c3 100644
@@ -179,6 +179,16 @@ config ACPI_NUMA
 	depends on (X86 || IA64)
 	default y if IA64_GENERIC || IA64_SGI_SN2
 
+config ACPI_WMI
+	tristate "WMI ACPI Interface (EXPERIMENTAL)"
+	depends on EXPERIMENTAL
+	help
+	  This driver adds support for the WMI ACPI device (PNP0C14) found on
+	  some systems.
+
+	  NOTE: You will need another driver on top of this to actually use
+	  anything defined in the WMI ACPI device.
+
 config ACPI_ASUS
         tristate "ASUS/Medion Laptop Extras"
 	depends on X86
drivers/acpi/Makefile +1 -0
index 54e3ab0..9e9aa39 100644
@@ -55,6 +55,7 @@ obj-$(CONFIG_ACPI_THERMAL)	+= thermal.o
 obj-$(CONFIG_ACPI_SYSTEM)	+= system.o event.o
 obj-$(CONFIG_ACPI_DEBUG)	+= debug.o
 obj-$(CONFIG_ACPI_NUMA)		+= numa.o
+obj-$(CONFIG_ACPI_WMI)		+= wmi.o
 obj-$(CONFIG_ACPI_ASUS)		+= asus_acpi.o
 obj-$(CONFIG_ACPI_TOSHIBA)	+= toshiba_acpi.o
 obj-$(CONFIG_ACPI_HOTPLUG_MEMORY)	+= acpi_memhotplug.o
drivers/acpi/wmi.c new file +480 -0

480 lines not on this page · raw message

include/linux/acpi.h +14 -0
index 8ccedf7..72c9609 100644
@@ -186,6 +186,20 @@ extern int ec_transaction(u8 command,
 
 #endif /*CONFIG_ACPI_EC*/
 
+#ifdef CONFIG_ACPI_WMI
+
+extern acpi_status wmi_evaluate_method(const char *guid, u32 instance,
+					u32 method_id,
+					const struct acpi_buffer *in,
+					struct acpi_buffer *out);
+extern acpi_status wmi_query_block(const char *guid, u32 instance,
+					u32 method_id, struct acpi_buffer *out);
+extern acpi_status wmi_set_block(const char *guid, u32 instance, u32 method_id,
+					const struct acpi_buffer *in);
+extern bool wmi_has_guid(char *guid);
+
+#endif	/* CONFIG_ACPI_WMI */
+
 extern int acpi_blacklisted(void);
 extern void acpi_bios_year(char *s);
 
Signature · 1 line
1.5.3.4
#1 lore raw

Len,

Quoted 2 lines · On Friday 05 October 2007 00:37:34 Carlos Corbacho wrote:

The following is my own basic implementation of a Windows Management Instrumentation (WMI) ACPI interface mapper (PNP0C14).

I would still like to see your work on WMI (my work on this is just to give an idea about how I see a WMI mapper working, in conjunction with another driver (and for the practise of writing another driver)).

-Carlos

Signature · 3 lines
E-Mail: [email protected]
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D