With ACPI 5 it is now possible to enumerate traditional SoC
peripherals, like serial bus controllers and slave devices behind
them.  These devices are typically based on IP-blocks used in many
existing SoC platforms and platform drivers for them may already
be present in the kernel tree.

To make driver "porting" more straightforward, add ACPI support to
the platform bus type.  Instead of writing ACPI "glue" drivers for
the existing platform drivers, register the platform bus type with
ACPI to create platform device objects for the drivers and bind the
corresponding ACPI handles to those platform devices.

This should allow us to reuse the existing platform drivers for the
devices in question with the minimum amount of modifications.

This changeset is based on Mika Westerberg's and Mathias Nyman's
work.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NH. Peter Anvin <hpa@zytor.com>
Acked-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Drivers may make calls that require the ACPI IPMI driver to have been
initialised already, so make sure that it appears earlier in the build
order.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

ACPI 5.0 adds the BGRT, a table that contains a pointer to the firmware
boot splash and associated metadata. This simple driver exposes it via
/sys/firmware/acpi in order to allow bootsplash applications to draw their
splash around the firmware image and reduce the number of jarring graphical
transitions during boot.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

With the conversion of atomicio's routines in place (see commits
6f68c91c and 700130b4), atomicio.[ch] can be removed, replacing
the APEI specific pre-mapping capabilities with the more generalized
versions that drivers/acpi/osl.c provides.
Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Some firmware will access memory in ACPI NVS region via APEI.  That
is, instructions in APEI ERST/EINJ table will read/write ACPI NVS
region.  The original resource conflict checking in APEI code will
check memory/ioport accessed by APEI via general resource management
mechanism.  But ACPI NVS region is marked as busy already, so that the
false resource conflict will prevent APEI ERST/EINJ to work.

To fix this, this patch record ACPI NVS regions, so that we can avoid
request resources for memory region inside it.
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

With /sys/kernel/debug/acpi/custom_method root can write
to arbitrary memory and increase his priveleges, even if
these are restricted.

-> Make this an own debug .config option and warn about the
security issue in the config description.

-> Still keep acpi/debugfs.c which now only creates an empty
   /sys/kernel/debug/acpi directory. There might be other
   users of it later.
Signed-off-by: NThomas Renninger <trenn@suse.de>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: rui.zhang@intel.com
Signed-off-by: NLen Brown <len.brown@intel.com>

As discussed earlier, the ACPI power meter driver would better live
in drivers/hwmon, as its only purpose is to create hwmon-style
interfaces for ACPI 4.0 power meter devices. Users are more likely to
look for it there, and less likely to accidentally hide it by
unselecting its dependencies.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: N"Darrick J. Wong" <djwong@us.ibm.com>
Acked-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Cc: Len Brown <lenb@kernel.org>

The saving of the ACPI NVS area during hibernation and suspend and
restoring it during the subsequent resume is entirely specific to
ACPI, so move it to drivers/acpi and drop the CONFIG_SUSPEND_NVS
configuration option which is redundant.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

ACPI 4.0 spec adds the ACPI IPMI opregion, which means that the ACPI AML
code can also communicate with the BMC controller. This is to install
the ACPI IPMI opregion and enable the ACPI to access the BMC controller
through the IPMI message.

     It will create IPMI user interface for every IPMI device detected
in ACPI namespace and install the corresponding IPMI opregion space handler.
Then it can enable ACPI to access the BMC controller through the IPMI
message.

The following describes how to process the IPMI request in IPMI space handler:
    1. format the IPMI message based on the request in AML code.
    IPMI system address. Now the address type is SYSTEM_INTERFACE_ADDR_TYPE
    IPMI net function & command
    IPMI message payload
    2. send the IPMI message by using the function of ipmi_request_settime
    3. wait for the completion of IPMI message. It can be done in different
routes: One is in handled in IPMI user recv callback function. Another is
handled in timeout function.
    4. format the IPMI response and return it to ACPI AML code.

At the same time it also addes the module dependency. The ACPI IPMI opregion
will depend on the IPMI subsystem.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Rmove deprecated ACPI procfs I/F, including
/proc/acpi/debug_layer
/proc/acpi/debug_level
/proc/acpi/info
/proc/acpi/dsdt
/proc/acpi/fadt
/proc/acpi/sleep

because the sysfs I/F is already available
and has been working well for years.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Introduce drivers/acpi/sysfs.c.

code for ACPI sysfs I/F, including
#ifdef ACPI_DEBUG
/sys/module/acpi/parameters/debug_layer
/sys/module/acpi/parameters/debug_level
/sys/module/acpi/parameters/trace_method_name
/sys/module/acpi/parameters/trace_debug_layer
/sys/module/acpi/parameters/trace_debug_level
/sys/module/acpi/parameters/trace_state
#endif
/sys/module/acpi/parameters/acpica_version
/sys/firmware/acpi/tables/
/sys/firmware/acpi/interrupts/
is moved to this file.

No function change in this patch.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Introduce drivers/acpi/debugfs.c.

Code for ACPI debugfs I/F,
i.e. /sys/kernel/debug/acpi/custom_method,
is moved to this file.

And make ACPI debugfs always built in,
even if CONFIG_ACPI_DEBUG is cleared.

BTW:this adds about 400bytes code to ACPI, when
CONFIG_ACPI_DEBUG is cleared.

[uaccess.h build fix from Andrew Morton <akpm@linux-foundation.org>]
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This patch provides the same information through debugfs, which previously was
provided through /proc/acpi/embedded_controller/*/info

This is the gpe the EC is connected to and whether the global lock
gets used.
The io ports used are added to /proc/ioports in another patch.
Beside the fact that /proc/acpi is deprecated for quite some time,
this info is not needed for applications and thus can be moved
to debugfs instead of a public interface like /sys.
Signed-off-by: NThomas Renninger <trenn@suse.de>

CC: Alexey Starikovskiy <astarikovskiy@suse.de>
CC: Len Brown <lenb@kernel.org>
CC: linux-kernel@vger.kernel.org
CC: linux-acpi@vger.kernel.org
CC: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: platform-driver-x86@vger.kernel.org
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Hardware Error Device (PNP0C33) is used to report some hardware errors
notified via SCI, mainly the corrected errors. Some APEI Generic
Hardware Error Source (GHES) may use SCI on hardware error device to
notify hardware error to kernel.

After receiving notification from ACPI core, it is forwarded to all
listeners via a notifier chain. The listener such as APEI GHES should
check corresponding error source for new events when notified.
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Now, a dedicated HEST tabling parsing code is used for PCIE AER
firmware_first setup. It is rebased on general HEST tabling parsing
code of APEI. The firmware_first setup code is moved from PCI core to
AER driver too, because it is only AER related.
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Reviewed-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

APEI stands for ACPI Platform Error Interface, which allows to report
errors (for example from the chipset) to the operating system. This
improves NMI handling especially. In addition it supports error
serialization and error injection.

For more information about APEI, please refer to ACPI Specification
version 4.0, chapter 17.

This patch provides some common functions used by more than one APEI
tables, mainly framework of interpreter for EINJ and ERST.

A machine readable language is defined for EINJ and ERST for OS to
execute, and so to drive the firmware to fulfill the corresponding
functions. The machine language for EINJ and ERST is compatible, so a
common framework is defined for them.
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Some ACPI IO accessing need to be done in atomic context. For example,
APEI ERST operations may be used for permanent storage in hardware
error handler. That is, it may be called in atomic contexts such as
IRQ or NMI, etc. And, ERST/EINJ implement their operations via IO
memory/port accessing.  But the IO memory accessing method provided by
ACPI (acpi_read/acpi_write) maps the IO memory during it is accessed,
so it can not be used in atomic context. To solve the issue, the IO
memory should be pre-mapped during EINJ/ERST initializing. A linked
list is used to record which memory area has been mapped, when memory
is accessed in hardware error handler, search the linked list for the
mapped virtual address from the given physical address.
Signed-off-by: NHuang Ying <ying.huang@intel.com>
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

We've renamed the old processor_core.c to processor_driver.c, to
convey the idea that it can be built modular and has driver-like
bits.

Now let's re-create a processor_core.c for the bits needed
statically by the rest of the kernel. The contents of processor_pdc.c
are a good starting spot, so let's just rename that file and
complete our three card monte.
Acked-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The ACPI processor driver can be built as a module. But it has
pieces of code that should always be built statically into the
kernel.

The plan is for processor_core.c to contain the static bits while
processor_driver.c contains the module-like bits.

Since the bulk of the code in the current processor_core.c is
module-like, first step is to rename the file to processor_driver.c

Next step will re-create processor_core.c and cherry-pick out
the static bits.
Acked-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

We discovered that at least one machine (HP Envy), methods in the DSDT
attempt to call external methods defined in a dynamically loaded SSDT.

Unfortunately, the DSDT methods we are trying to call are part of the
EC initialization, which happens very early, and the the dynamic SSDT
is only loaded when a processor _PDC method runs much later.

This results in namespace lookup errors for the (as of yet) undefined
methods.

Since Windows doesn't have any issues with this machine, we take it
as a hint that they must be evaluating _PDC much earlier than we are.

Thus, the proper thing for Linux to do should be to match the Windows
implementation more closely.

Provide a mechanism to call _PDC before we enable the EC. Doing so loads
the dynamic tables, and allows the EC to be enabled correctly.

The ACPI processor driver will still evaluate _PDC in its .add() method
to cover the hotplug case.

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

Cc: ming.m.lin@intel.com
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Feedback from Hidetoshi Seto and Kenji Kaneshige incorporated.  This
correctly handles PCI-X bridges, PCIe root ports and endpoints, and
prints debug messages when invalid/reserved types are found in the
HEST.  PCI devices not in domain/segment 0 are not represented in
HEST, thus will be ignored.

Today, the PCIe Advanced Error Reporting (AER) driver attaches itself
to every PCIe root port for which BIOS reports it should, via ACPI
_OSC.

However, _OSC alone is insufficient for newer BIOSes.  Part of ACPI
4.0 is the new APEI (ACPI Platform Error Interfaces) which is a way
for OS and BIOS to handshake over which errors for which components
each will handle.  One table in ACPI 4.0 is the Hardware Error Source
Table (HEST), where BIOS can define that errors for certain PCIe
devices (or all devices), should be handled by BIOS ("Firmware First
mode"), rather than be handled by the OS.

Dell PowerEdge 11G server BIOS defines Firmware First mode in HEST, so
that it may manage such errors, log them to the System Event Log, and
possibly take other actions.  The aer driver should honor this, and
not attach itself to devices noted as such.

Furthermore, Kenji Kaneshige reminded us to disallow changing the AER
registers when respecting Firmware First mode.  Platform firmware is
expected to manage these, and if changes to them are allowed, it could
break that firmware's behavior.

The HEST parsing code may be replaced in the future by a more
feature-rich implementation.  This patch provides the minimum needed
to prevent breakage until that implementation is available.
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Reviewed-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: NMatt Domsch <Matt_Domsch@dell.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This driver exposes ACPI 4.0 compliant power meters as hardware monitoring
devices.  This second revision of the driver also exports the ACPI string
info as sysfs attributes, a list of the devices that the meter measures,
and will send ACPI notifications over the ACPI netlink socket.  This
latest revision only enables the power capping controls if it can be
confirmed that the power cap can be enforced by the hardware and explains
how the notification interfaces work.

[akpm@linux-foundation.org: remove default-y]
[akpm@linux-foundation.org: build fix]
Signed-off-by: NDarrick J. Wong <djwong@us.ibm.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

ACPI 4.0 created the logical "processor aggregator device" as
a mechinism for platforms to ask the OS to force otherwise busy
processors to enter (power saving) idle.

The intent is to lower power consumption to ride-out
transient electrical and thermal emergencies,
rather than powering off the server.

On platforms that can save more power/performance via P-states,
the platform will first exhaust P-states before forcing idle.
However, the relative benefit of P-states vs. idle states
is platform dependent, and thus this driver need not know
or care about it.

This driver does not use the kernel's CPU hot-plug mechanism
because after the transient emergency is over, the system must
be returned to its normal state, and hotplug would permanently
break both cpusets and binding.

So to force idle, the driver creates a power saving thread.
The scheduler will migrate the thread to the preferred CPU.
The thread has max priority and has SCHED_RR policy,
so it can occupy one CPU.  To save power, the thread will
invoke the deep C-state entry instructions.

To avoid starvation, the thread will sleep 5% of the time
time for every second (current RT scheduler has threshold
to avoid starvation, but if other CPUs are idle,
the CPU can borrow CPU timer from other,
which makes the mechanism not work here)

Vaidyanathan Srinivasan has proposed scheduler enhancements
to allow injecting idle time into the system.  This driver doesn't
depend on those enhancements, but could cut over to them
when they are available.

Peter Z. does not favor upstreaming this driver until
the those scheduler enhancements are in place.  However,
we favor upstreaming this driver now because it is useful
now, and can be enhanced over time.
Signed-off-by: NShaohua Li <shaohua.li@intel.com>
NACKed-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The battery driver tends to take quite some time to initialize
(100ms-300ms is quite typical).
This patch initializes the batter driver asynchronously, so that other
things in the kernel can initialize in parallel to this 300 msec.

As part of this, the battery driver had to move to the back
of the ACPI init order (hence the Makefile change).
Without this move, the next ACPI driver would just block
on the ACPI/devicee layer semaphores until the battery driver was
done anyway, not gaining any boot time.
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Suggested-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Impact: cleanup

Rather than overriding MODULE_PARAM_PREFIX, build via acpi.o so
KBUILD_MODNAME is set to "acpi".

This is the logical way to do it, even though acpi cannot be a module
due to these config options being bool.  Those parts of ACPI which can
be modular are not built into the acpi "module".
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NLen Brown <len.brown@intel.com>

This patch removes the suggestion that ec.o link order is important,
because it doesn't matter since acpi_ec_init() is no longer an initcall.
And it puts together most of the core modules that are not configurable.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Remove CONFIG_ACPI_SYSTEM.  It was always set the same as CONFIG_ACPI,
and it had no menu label, so there was no way to set it to anything
other than "y".

Some things under CONFIG_ACPI_SYSTEM (acpi_irq_handled, acpi_os_gpe_count(),
event_is_open, register_acpi_notifier(), etc.) are used unconditionally
by the CA, the OSPM, and drivers, so we depend on them always being
present.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NLen Brown <len.brown@intel.com>

also, delete sleep/ and delete ACPI_CFLAGS from Makefile
Signed-off-by: NLen Brown <len.brown@intel.com>

These are platform specific drivers that happen to use ACPI,
while drivers/acpi/ is for code that implements ACPI itself.
Signed-off-by: NLen Brown <len.brown@intel.com>

If an ACPI graphics device supports backlight brightness functions (cmp. with
latest ACPI spec Appendix B), let the ACPI video driver control backlight and
switch backlight control off in vendor specific ACPI drivers (asus_acpi,
thinkpad_acpi, eeepc, fujitsu_laptop, msi_laptop, sony_laptop, acer-wmi).

Currently it is possible to load above drivers and let both poke on the
brightness HW registers, the video and vendor specific ACPI drivers -> bad.

This patch provides the basic support to check for BIOS capabilities before
driver loading time. Driver specific modifications are in separate follow up
patches.

"acpi_backlight=vendor"
	Prever vendor driver over ACPI driver for backlight.
"acpi_backlight=video" (default)
	Prever ACPI driver over vendor driver for backlight.
Signed-off-by: NThomas Renninger <trenn@suse.de>
Acked-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Remove CONFIG_ACPI_EC.  It was always set the same as CONFIG_ACPI,
and it had no menu label, so there was no way to set it to anything
other than "y".

Per section 6.5.4 of the ACPI 3.0b specification,

    OSPM must make Embedded Controller operation regions, accessed
    via the Embedded Controllers described in ECDT, available before
    executing any control method.

The ECDT table is optional, but if it is present, the above text
means that the EC it describes is a required part of the ACPI
subsystem, so CONFIG_ACPI_EC=n wouldn't make sense.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

Remove CONFIG_ACPI_POWER.  It was always set the same as CONFIG_ACPI,
and it had no menu label, so there was no way to set it to anything
other than "y".

The interfaces under CONFIG_ACPI_POWER (acpi_device_sleep_wake(),
acpi_power_transition(), etc) are called unconditionally from the
ACPI core, so we already depend on it always being present.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

    There exists the following warning message will appear after the
following commit is merged.
   >commit f2e969acd6d5981e6b1272810002558650d0736e
   >Author: Zhao Yakui <yakui.zhao@intel.com>
   >Date:   Mon Aug 11 14:57:50 2008 +0800
    >ACPI: Add "acpi.power_nocheck=1" to disable power state check in
power transition:

   >WARNING: at linux-2.6/fs/sysfs/dir.c:463  sysfs_add_one+0x33/0x39()
   >sysfs: duplicate filename 'acpi' can not be created
   >kobject_add_internal failed for acpi with -EEXIST, don't try to register
            things with the same name in the same directory

   In the above commit the "acpi.power_nocheck" module parameter is defined
in drivers/acpi/power.c file. As several module parameters using the same ACPI
prefix are defined in the different files(for example: power_nocheck is
defined in drivers/acpi/power.c,debug_layer/debug_level are defined in
drivers/acpi/debug.c) and there exists another module between them, the
warning message will be printed when using the current generic param code.
(In the function of param_sysfs_init).

   In fact when ACPI is selected, the drivers/acpi/power will also be compiled
as built-in kernel.So this issue can be fixed by the following approach.
   workaround it by adjusting the module link order in drivers/acpi/Makefile.
In such case the module parameter using the same prefix(ACPI) are put together
in the param data section.

   Of course the better solution is to fix it in generic param code related
with sysfs.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NShaohua Li <shaohua.li@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NAaron Durbin <adurbin@google.com>
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>

Detect all physical PCI slots as described by ACPI, and create entries in
/sys/bus/pci/slots/.

Not all physical slots are hotpluggable, and the acpiphp module does not
detect them.  Now we know the physical PCI geography of our system, without
caring about hotplug.

[kaneshige.kenji@jp.fujitsu.com: export-kobject_rename-for-pci_hotplug_core]
Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Acked-by: NGreg KH <greg@kroah.com>
[akpm@linux-foundation.org: build fix]
[akpm@linux-foundation.org: fix build with CONFIG_DMI=n]
Signed-off-by: NAlex Chiang <achiang@hp.com>
Cc: Greg KH <greg@kroah.com>
Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Cc: Len Brown <lenb@kernel.org>
Acked-by: NLen Brown <len.brown@intel.com>
Acked-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

In static case sbshc must be compiled ahead of sbs, so that
hc is configured first.

http://bugzilla.kernel.org/show_bug.cgi?id=9910Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

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: NCarlos Corbacho <carlos@strangeworlds.co.uk>
CC: Matthew Garrett <mjg59@srcf.ucam.org>
CC: Alexey Starikovskiy <aystarik@gmail.com>
Signed-off-by: NLen Brown <len.brown@intel.com>