iASL: Fix range check for Memory24 resource descriptor.

Fix boundary case where AddressMaximum is equal to the
(Length - 1). ACPICA BZ 1098.
Disassembler/acpihelp: Add UUID for the _DSD method.

UUID to be used in conjunction with _DSD.
Tests: Enhance asltsrun script to understand new debug object output.

The AML debug object now outputs the value of the current ACPI Timer().
This broke the original script. This change makes the script independent
of the contents between the opening brackets.
David Box.
Linuxize: Add upstream commit ID in the generated patches.

This patch adds support to add ACPICA upstream Commit ID/Author in the
generated linuxized patches. This format follows Linux stable material
format. The modifications include:
1. distiguish COMMITTER, AUTHOR, MAINTAINER:
   1. COMMITTER is automatically extracted using "git config --get";
   2. AUTHOR is automatically extracted using "git log --format=%aN <%aE>";
   3. MAINTAINER is fixed in make-patches.sh, currently it is
      "Bob Moore <robert.moore@intel.com>".
2. add AUTHOR and COMMIT ID information to form the ACPICA release patch
   header.
3. automatically correct "Robert Moore <Robert.Moore@intel.com>" to
   "Bob Moore <bob.moore@intel.com>".
4. automatically remove last empty lines in the patch description.
5. automatically append unique Signed-off-by for AUTHOR, NAINTAINER and
   COMMITTER.
6. automatically add commit URL before SOBs and add "-l" option to be ready
   for changing the host of the repo.
The generated patch format is ACKed by the Linux ACPI maintainer. Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Events: Fix an issue that AcpiSetGpe() cannot unconditionally enable GPEs.

AcpiEvEnableGpe() is invoked by:
1. AcpiSetGpe()
2. AcpiEnableGpe()
3. AcpiRemoveGpeHandler()
4. AcpiUpdateAllGpes
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 without the GPE clearing logic implemented in it.

This patch adds unconditional GPE enabling support into AcpiSetGpe().

Originally this function checks if the GPE has been enabled with handlers
and performs acknowledging before enabling it.

First, IRQ enabling/disabling has 2 use cases:
1. When upper layers (the users of the driver) submit requests to the
   drivers, it means they care about the underlying hardware. For this
   case, AcpiEnableGpe() should be invoked. When the reference count is
   increased from 0 to 1, driver enables the hardware IRQ. And
   AcpiDisableGpe() is used as the reversal when the users have completed
   the submitted requests.
2. Driver may temporarily disables the IRQ and wants to re-enable it later,
   this case is normally used in order to prevent IRQ storm. 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
   and re-enables it in the defered execution environment - which should be
   in a task context. This API should be used exactly for this purpose.

Second, since the AcpiSetGpe() should be invoked from an IRQ handler, the
handler check is useless for this API.

Third, 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).

Fourth, GPE clearing is used to acknowledge the GPE. The combination of
acknowledging and enabling may 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. For example, a high IO
throughput IRQ requires the IRQ to be cleared in the IRQ context. In order
to avoid GPE storm, same driver need to invoke IRQ re-enabling in the task
context. 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.

This patch converts AcpiSetGpe(ACPI_GPE_ENABLE) into
AcpiHwLowSetGpe(ACPI_GPE_ENABLE) to achieve a seperate GPE enabling API.
Drivers are encouraged to use this API when they need to handle the above
mentioned cases. Lv Zheng.

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: Fix an issue that status of GPEs are unexpectedly cleared.

AcpiEvEnableGpe() is invoked by:
1. AcpiSetGpe()
2. AcpiEnableGpe()
3. AcpiRemoveGpeHandler()
4. AcpiUpdateAllGpes
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 without the GPE clearing logic implemented in it.

This patch checks the requirements for the logics implemented in the
original AcpiEnableGpe() that are conflict with our improvements.

For "stale events clearing", AcpiEnableGpe() now can only be invoked in the
task context without knowing whether there is a IRQ raised or not. This is
a dangerous behavior because IRQ status should be cleared unless the code
know it is handling an IRQ, or for edge triggered IRQs, the IRQ indicating
a event cleared by this API cannot be raised after leaving the task
context, if the driver doesn't implement polling mode for this event, the
event can never be seen by the driver. This is an IRQ loss case. We may
see such issues in the system PM suspend/resume code or request based
runtime PM code. For level triggered IRQ, clearing in the task context
cannot stop from this to be indicated again.
By enforcing the GPE status clearing only in the IRQ handlers, we can fix
this issue. So let's check the cases for the task context we may need it
before removing this logic:
1. By implementing state machine correctly, driver can clean the conditions
   that trigger such GPE status, some silicon logics may be able to clear
   the GPE status automatically after the conditions have been cleared, so
   the drivers are safe to poll the hardware without clearing the GPE
   status.
2. Even for the silicon logics that cannot clear the GPE status
   automatically, since the drivers should be ready for the shared IRQs,
   the drivers should have already implemented IRQ handlers to check the
   individual hardware condition bits. A GPE raised without any individual
   hardware condition bit indicated will only invoke the IRQ handler as a
   no-op. So the drivers are still safe to work in the polling mode without
   clearing the GPE status in the task context, it only adds 1 no-op IRQ
   handler invocation overhead, this IRQ handler invocation clears the
   status bit without doing anything else.
3. If there are arbitrary "stale events" (for example, silicon bugs) upon
   enabling the IRQ, the driver's IRQ handler should be able to detect and
   handle them as no-ops like the case 2. In such case, the no-op IRQ
   handler invocations will be more than once and the driver will still not
   be broken by switching between the IRQ mode and the polling mode. Note
   that such "stale events" will be treated as an IRQ storm triggered by
   the buggy silicons. Even for the IRQ only mode, the storms will remain
   there. So this should be handled by the storm prevention logics
   implemented in the driver.
4. As a conclusion, there should be no situation to peform "stale events
   clearing" out side of IRQ handler when the OSPM driver is ready. It
   might be required by AcpiUpdateAllGpes() to work around some firmware
   bugs during the OSPM booting period where the OSPM driver is not ready.
   Though correct _Lxx/_Exx should be capable of handling such events like
   the case 2, without knowing the real issues the AcpiUpdateAllGpes() is
   trying to handle (it might be _Lxx/_Exx bugs), in order not to trigger
   regressions, we may need to keeps this logic for this function.

So this patch:
1. Moves "unconditional GPE enabling" to AcpiEvAddGpeReference() as it
   should only be invoked by OSPM code and removing this can help us to
   find some lost GPEs back for the OSPM drivers.
2. Moves "stale events clearing" to AcpiEvIntializedGpeBlock() (which is
   invoked by AcpiUpdateAllGpes()), where this might still be needed for
   some BIOSes as a useful work around after booting.

Along with the previous cleanups, all AcpiEvEnableGpe() usages are removed,
this patch can also remove this internal API. Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Events: Fix an issue that GPE APIs cannot be invoked in atomic context.

The GPE APIs should be invoked inside of an IRQ context GPE handler or in
the task context with a driver provided lock held. This driver provided
lock should be safe to be held in the GPE handler by the driver.

While currently we cannot do this, thus we can only use the GPE APIs for
limitted cases.

This patch adds reference counting for ACPI_GPE_HANDLER_INFO. Then the GPE
handler can be safely invoked without holding the GPE lock, thus
facilitates GPE APIs to be invoked in any atomic environment. Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Events: Fix an issue that GPE APIs cannot be invoked in deferred handlers.

The AcpiOsWaitEventsComplete() is used for flushing the deferred executed
handlers, invoking it for GPE interrupt handlers doesn't help to protect
GPE handler callback.  On the contrary, it prevents GPE APIs from being
invoked in the deferred notify handlers.

Actually, the GPE interrupt handlers' invocation is protected by the
previous implemented reference counting mechanism.

This patch fixes this GPE APIs invocation issue in a seperate commit other
than the reference counting one, so that if any regressions are reported,
this patch can be temporarily reverted before the regressions are root
caused. Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Events: Fix an issue that OriginallyEnabled check is not paired.

The OriginallyEnabled check is not paired between AcpiInstallGpeHandler()
and AcpiRemoveGpeHandler(). Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Events: Add a flag to disable internal auto GPE clearing.

Clearing the status bit means OSPM acknowledges the GPE and the hardware
then can bring follow-up events up. Acklowdging it too early causes OSPM
seeing leve-triggered GPE storms or missing edge-triggered GPEs if the
OSPM driver responds slowly. Some drivers may choose to implement GPE
condition clearing code in a position that is different from where it
should be disabled or re-enabled and some silicon can implement special
GPE status as R1C (read once clear). For those case, the internal auto
GPE clearing operations should be abandoned.

This flag facilitates such driver designs and implementations.

Note that drivers will need to invoke AcpiClearGpe() manually in a proper
position where the causes and conditions of the GPE have been solved and
the GPE status can be safely cleared. Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Events: Add a flag to disable internal auto GPE disabling.

The ACPI specification around the GPE handling is talking about a threaded
IRQ model (which is also known as the IRQ polling mode comparing to the
interrupted IRQ mode). GPE is disabled in the IRQ context and re-enabled in
the IRQ polling thread (task context) after the interrupt has been
correctly handled.

For interrupted IRQ mode IRQ handler (ACPICA GPE dispatcher can only be
implemented in this mode), disabling IRQ is useless as IRQ is automatically
disabled before invoking the handler for the same CPU. There is no hardware
in the real world can trigger an IRQ on the same CPU to preempt the handler
of the same IRQ.

And the automatic IRQ disabling is harmful to request based low power IO
drivers where IRQ enabling/disabling is managed by the power references and
the storm conditions.
The IRQ disabling/enabling out of the drivers' control can mess up the IRQ
enabling state where:
1. Enabling IRQ means there is more than 1 requests and no storms;
2. Disabling IRQ means there is no request or there is a storm.

This patch adds a flag to control the ACPICA internal GPE disabling to
facilitate request based low power IO drivers to work in the GPE level.

Since we will have users for the new GPE flag to enable a runtime idle
style GPE driver, this patch also enables AcpiInstallGpeHandler() to
configure NO_AUTO_x flags. Lv Zheng.

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