acpisrc: Fix for last few warnings from ACPICA source processing.

Now processes the entire ACPICA C source tree with no warnings.
Added additional hardening against faults when processing.
Tests/aapits: Fix a file handle memory leak.

In atexec.c. ACPICA BZ 1095.
Tests/aapits: Eliminate unreachable code warnings.

Temporarily remove a block of code that could not be reached,
pending further investigation. Eliminates unreachable code
warnings.
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: 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 AcpiSetGpe() cannot unconditionally enable GPEs.

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

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
   re-enables it later to return to the IRQ interrupt mode in order to:
   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 IRQ
   polling mode.

This patch checks the requirements for the "stale events clearing" logic
implemented in the original AcpiEnableGpe() that are conflict with our
improvements.

The "stale events clearing" logic is implemented in AcpiEvEnableGpe() which
is invoked by:
1. AcpiEnableGpe()
2. AcpiRemoveGpeHandler()
3. AcpiUpdateAllGpes()
They are all invoked from the task context now. So "stale events clearing"
might be there only for the following use cases:
1. The IRQ polling mode when the OSPM driver is ready.
2. The system initialzation when the owner of the GPE is switched.

Using this logic in AcpiEnableGpe() is conflict with our improvement
because performing "stale events clearing" without knowing whether there is
an IRQ raised or not (for example, when enabling it) can break the request
based IRQ enabling mechanism.
1. For edge triggered IRQs, the IRQ indicating an 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.
2. For level triggered IRQ, clearing in the task context cannot stop GPE
   from being indicated again, some level triggered GPE clearing may issue
   actions to hardware (for example, starting to clock in the data in the
   write FIFO), the unexpected clearing then issues wrong actions to the
   hardware.
So we need to cleanup the "stale events clearing" logic from
AcpiEnableGpe(). By enforcing the GPE status clearing only in the IRQ
handling code fragment where the GPE is known to be raised, we can achieve
this.

For the first use case:
When the OSPM driver is ready, ACPICA will mark such GPE as
DISPATCH_HANDLER. Currently we have GPE status clearing code implemented
for IRQ interrupt mode, let's check whether we need to add GPE status
clearing code for the IRQ polling mode. Supposing OSPM drivers have already
implemented correct state machines or the drivers should have already been
broekn.
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 work in the polling mode 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 silicon chips. Even for the interrupt only mode, the storms
   will remain there. So this should be handled by the storm prevention
   logics implemented in the driver.
As a conclusion, it's safe without adding "GPE status clearing" code for
the IRQ polling mode.

For the second use case:
When the OSPM driver is not ready:
1. We relies on the BIOS provided _Lxx/_Exx control methods to handle the
   GPE and ACPICA will mark such GPEs as DISPATCH_METHOD. The BIOS provided
   methods might be buggy and cannot handle the GPEs correctly. Without
   knowing the real issues the AcpiUpdateAllGpes() is trying to handle, in
   order not to trigger regressions, we may need to keeps this logic for
   this function. Even we don't keep this logic, it is still safe because
   in AcpiEvGpeDispatch()/AcpiEvFinishGpe(), such IRQs can be automatically
   cleared upon firing and clearing before enabling it cannot prevent the
   bugs.
2. Another case is the _PRW, if there is no corresponding method or OSPM
   IRQ handler ready to handle such GPE, this kind of GPE will be marked as
   DISPATCH_NOTIFY if AcpiSetGpeForWake() is invoked. We may worry about
   false _PRW GPEs raised during the system bootup process and this is the
   only case we need the clearing code in AcpiEnableGpe() as
   AcpiEnableGpe() might be invoked before AcpiUpdateAllGpes(). But such
   false GPEs can still be automatically cleared upon firing. Such GPEs
   normally needn't any handling code other than the GPE status clearing,
   so we can just let the internal clearing code working for them.

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(). This patch contains the code that is already in
the Linux upstream. Lv Zheng.

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

The GPE status clearing code should be invoked in the GPE handling code.
There are cases that the GPE is handled in the polling mode and the IRQ
mode handler is a no-op. For which, ACPICA internal clearing should be
bypassed.
Some silicon chips can implement special GPE status as R1C (read once
clear). For those case, the internal auto GPE clearing operations should
also be abandoned.

This flag facilitates such driver designs and implementations.

Note that drivers will need to invoke AcpiClearGpe() manually in a proper
position. 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 an IRQ
handling code of IRQ polling mode (which is also known as the threaded IRQ
model in Linux) that is suitable for the control method execution. GPE is
disabled in the IRQ context and re-enabled in the IRQ polling context (the
task context of the polling thread) after the interrupt has been correctly
handled.

For IRQ handling code of IRQ interrupt mode (DISPATCH_HANDLER can only be
implemented in this mode), disabling IRQ is useless as further IRQs with
same IRQ no. are ensured to be blocked IRQ 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. There might be same IRQ handlers triggered on
different CPUs but disabling it in the IRQ handler cannot prevent this from
happening.

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>