acpiexec: Fix incorrect return value.

Late handler installation function was returning bad status
incorrectly.
Disassembler/acpihelp: Add new _HID values.

Added some new _HIDs that are recognized, along with their
description strings.
Add string for _DDN method name.

The _DDN method will be used internally.
Update to GPIO region handler interface.

Changes to correct several GPIO issues:

1) The UpdateRule in a GPIO field definition is now ignored;
a read-modify-write operation is never performed for GPIO fields.
(Internally, this means that the field assembly/disassembly
code is completely bypassed for GPIO.)

2) The Address parameter passed to a GPIO region handler is
now the bit offset of the field from a previous Connection()
operator. Thus, it becomes a "Pin Number Index" into the
Connection() resource descriptor.

3) The BitWidth parameter passed to a GPIO region handler is
now the exact bit width of the GPIO field. Thus, it can be
interpreted as "number of pins".

Overall, we can now say that the region handler interface
to GPIO handlers is a raw "bit/pin" addressed interface, not
a byte-addressed interface like the SystemMemory handler interface.

For Linux, this patch will need to be applied simultaneously
with the Linux GPIO handler patch that supports it.
Events: Fix an issue that OriginallyEnabled check is not paired.

The OriginallyEnabled check is not paired between AcpiInstallGpeHandler()
and AcpiRemoveGpeHandler(). This patch contains the code that is already in
the Linux kernel upstream. Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Events: Back port new event flags from Linux kernel to reduce divergences.

This patch is back ported from Linux kernel with modification to follow
ACPICA internal coding style and structure. Linux currently is using
AcpiGetEventStatus()/AcpiGetGpeStatus() to provide fixed event/GPE
information to the userspace via sysfs.
In Linux, AcpiGetEventStatus() returns ACPI_EVENT_FLAG_HANDLE (handler
installed) and ACPI_EVENT_FLAG_SET (status register set) for the fixed
event and AcpiGetGpeStatus() returns an additional ACPI_EVENT_FLAG_HANDLE
(dispatcher set). This patch back ports these behaviors.
When the code is back ported, the following things are changed:
1. The coding style is changed to follow ACPICA preference.
2. The ACPI_EVENT_FLAG_HANDLE is returned from AcpiHwGetGpeStatus()
   instead of set it after invoking AcpiHwGetGpeStatus().
3. In AcpiGetEventStatus(), a local variable local_event_status is
   introduced to make the piece of code similar as AcpiGetGpeStatus().
This patch is tested under Linux using sysfs interfaces. Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Events: Disable GPEs during initialization

GPEs with corresponding _Lxx/_Exx control methods need to be disabled
during initialization in case they have been enabled by the BIOS, so that
they don't fire up until they are enabled by AcpiUpdateAllGpes().
Rafael J. Wysocki.

References: https://bugzilla.kernel.org/show_bug.cgi?id=25412
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Events: Remove duplicated sanity check in AcpiEvEnableGpe().

This patch deletes a sanity check from AcpiEvEnableGpe().

This kind of check is already done in
AcpiEnableGpe()/AcpiRemoveGpeHandler()/AcpiUpdateAllGpes() before invoking
AcpiEvEnableGpe():
1. AcpiEnableGpe(): same check (skip if DISPATCH_NONE) is now implemented.
2. AcpiRemoveGpeHandler(): a more strict check (skip if !DISPATCH_HANDLER)
                           is implemented.
3. AcpiUpdateAllGpes(): a more strict check (skip if DISPATCH_NONE ||
                        DISPATCH_HANDLER || CAN_WAKE)
4. AcpiSetGpe(): since it is invoked by the OSPM driver where the IRQ
                 handler is known to be available, such check isn't needed.
So we can simply remove this duplicated check from AcpiEvEnableGpe().
Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Events: Introduce ACPI_GPE_RAW_HANDLER to fix 2 issues for the current GPE APIs.

Since whether the GPE should be disabled/enabled/cleared should only be
determined by the GPE driver's state machine:
1. GPE should be disabled if the driver wants to switch to the GPE polling
   mode when a GPE storm condition is indicated and should be enabled if
   the driver wants to switch back to the GPE interrupt mode when all of
   the storm conditions are cleared. The conditions should be protected by
   the driver's specific lock.
2. GPE should be enabled if the driver has accepted more than one request
   and should be disabled if the driver has completed all of the requests.
   The request count should be protected by the driver's specific lock.
3. GPE should be cleared either when the driver is about to handle an edge
   triggered GPE or when the driver has completed to handle a level
   triggered GPE. The handling code should be protected by the driver's
   specific lock.
Thus the GPE enabling/disabling/clearing operations are likely to be
performed with the driver's specific lock held while we currently cannot do
this. This is because:
1. We have the AcpiGbl_GpeLock held before invoking the GPE driver's
   handler. Driver's specific lock is likely to be held inside of the
   handler, thus we can see some dead lock issues due to the reversed
   locking order or recursive locking. In order to solve such dead lock
   issues, we need to unlock the AcpiGbl_GpeLock before invoking the
   handler. BZ 1100.
2. Since GPE disabling/enabling/clearing should be determined by the GPE
   driver's state machine, we shouldn't perform such operations inside of
   ACPICA for a GPE handler to mess up the driver's state machine. BZ 1101.
Originally this patch includes a logic to flush GPE handlers, it is dropped
due to the following reasons:
1. This is a different issue;
2. Currently all Linux GPE drivers are either protected by AcpiGbl_GpeLock
   or not a removable module, thus this is not an existing issue for now.
We will pick up this topic when a removable GPE driver uses the raw GPE
handling model.

Note that currently the internal operations and the AcpiGbl_GpeLock are
also used by ACPI_GPE_DISPATCH_METHOD and ACPI_GPE_DISPATCH_NOTIFY, in
order not to introduce regressions, we add one ACPI_GPE_RAW_HANDLER flag to
be paired with ACPI_GPE_DISPATCH_HANDLER. For which the AcpiGbl_GpeLock is
unlocked before invoking the GPE handler and the internal
enabling/disabling/clearing operations are bypassed to allow drivers to
perform them at a proper position using the GPE APIs. Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Events: Enable APIs to allow interrupt/polling adaptive request based GPE handling model.

For AcpiSetGpe()/AcpiEnableGpe(), our target is to purify them to be APIs
can be used for request based driver handling code, so we need them to be
pure GPE enabling APIs. IRQ enabling/disabling has 2 use cases:
1. Driver may permanently enable/disable IRQs according to the usage
   counts.
   1. When upper layers (the users of the driver) submit requests to the
      driver, it means they care about the underlying hardware. IRQ need
      to be enabled for the first request submission and disabled for the
      last request completion.
   2. When the IRQ is shared between 2+ silicon logics. IRQ need to be
      enabled for either silicon logic's driver and disabled when all of
      the drivers are not started.
   For these cases, AcpiEnableGpe()/AcpiDisableGpe() should be used. When
   the usage count is increased from 0 to 1, the IRQ is enabled and it is
   disabled when the usage count is decrased from 1 to 0.
2. Driver may temporarily disables the IRQ to enter an IRQ polling mode and
   wants to re-enable it later.
   1. Prevent IRQ storming: when a driver cannot fully solve the condition
      that triggered the IRQ in the IRQ context, in order not to trigger
      IRQ storm, driver has to disable IRQ to switch into the polling mode
      and re-enables it in the non-IRQ context after the storming condition
      is cleared.
   2. Meet throughput requirement: some IO drivers need to poll hardware
      again and again until nothing indicated instead of just handling once
      for one interruption, this need to be done in the polling mode or the
      IO flood may prevent the IRQ handler from returning.
   3. Meet realtime requirement: in order not to block CPU to handle higher
      realtime prioritized IRQs, lower priority IRQs can be handled in the
      polling mode.
   For these cases, AcpiSetGpe() should be used to switch to/from the
   polling mode.

This patch adds unconditional GPE enabling support into AcpiSetGpe() so
that this API can be used by the drivers to switch back from the GPE
polling mode unconditionally.

Originally this function includes GPE clearing logic in it.
First, the GPE clearing is typically used in the GPE handling code to:
1. Acknowledge the GPE when we know there is an edge triggered GPE raised
   and is about to handle it, otherwise the unexpected clearing may lead to
   a GPE loss;
2. Issue actions after we have handled a level triggered GPE, otherwise
   the unexpected clearing may trigger unwanted OSPM actions to the
   hardware (for example, clocking in out-dated write FIFO data).
Thus the GPE clearing is not suitable to be used in the GPE enabling APIs.
Second, the combination of acknowledging and enabling may also not be
expected by the hardware drivers. For GPE clearing, we have a seperate API
AcpiClearGpe(). There are cases drivers do want the 2 operations to be
split. So splitting these 2 operations could facilitates drivers the
maximum possibilities to achieve success. For a combined one, we already
have AcpiFinishGpe() ready to be invoked.

Given the fact that drivers should complete all outstanding requests before
putting themselves into the sleep states, as this API is executed for
outstanding requests, it should also have nothing to do with the
"RUN"/"WAKE" distinguishing. That's why the AcpiSetGpe(ACPI_GPE_ENABLE)
should not be implemented by AcpiHwLowSetGpe(ACPI_GPE_CONDITIONAL_ENABLE).

This patch thus converts AcpiSetGpe(ACPI_GPE_ENABLE) into
AcpiHwLowSetGpe(ACPI_GPE_ENABLE) to achieve a seperate GPE enabling API.
Drivers then are encouraged to use this API when they need to switch
to/from the IRQ polling mode. Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Events: Introduce AcpiForceGpe() to fix an issue that the debugger cannot enable/disable GPE unconditionally.

There is a facility in Linux, developers can force GPE enabling/disabling
through /sys/firmware/acpi/interrupts/gpexx. This is mainly for debugging
purposes because such GPE enabling/disabling operations are out of the
drivers' control and hence are dangerous for the following conditions:
1. If the drivers are not IRQ polling capable and the disaling is forced,
2. If the drivers are not interrupted IRQ capable and the enabling is
   forced.

Currently this facility invokes reference counting based GPE enabling APIs
- AcpiEnableGpe()/AcpiDisableGpe(), which has confused users for so long
time as:
1. Such APIs could not disable the GPE unless the GPE is not shared, not
   wakeup capable and not enabled by the driver more than once.
This facility also breaks system wakeup code and drivers by messing up the
reference count.

This patch introduces AcpiForceGpe() to be used in such situation instead
of AcpiEnableGpe()/AcpiDisableGpe().
It is said that the stale events clearing is required by this facility to
avoid wrong _Lxx/_Exx method invocations caused by the events appeared
during the forced-disabling period, and the clearing is working because
most of such GPEs are used for system wakeup purposes and can be simply
acknowledged by clearing the GPE status without taking any additional
responses. Thus this patch keeps this logic in the new API.

This patch also modifies AcpiGetGpeStatus() to return more information
from ACPICA core to reflect this forced status.

The old ACPI_EVENT_FLAG_SET is carefully kept to avoid regressions. It can
be deleted after we can make sure all its references are removed from OSPM
code. Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>