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.
7. fix the issue that the default "commit ID" for gen-patch.sh is not
   implemented.
8. distiguish upstream generation and local generation using "-u" option.
The generated patch format with upstream commit ID is ACKed by the Linux
ACPI maintainer. Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Events: Clear all non-wakeup GPEs in AcpiHwEnableWakeupGpeBlock()

Since AcpiHwEnableWakeupGpeBlock() is currently always called after
disabling all GPEs, it can actually write zeros to all non-wakeup enable
bits unconditionally.

That will be useful going forward for disabling runtime GPEs and enabling
wakeup GPEs in one go instead of doing that in two steps (disable runtime
and enable wakeup) which in theory may lead to a loss of a wakeup event.
Rafael J. Wysocki.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Events: Introduce AcpiEnableAllWakeupGpes()

Add a routine for host OSes to enable all wakeup GPEs and disable all of
the non-wakeup ones at the same time.

It will be used for the handling of GPE wakeup from suspend-to-idle in
Linux.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Events: Save current masks of enabled GPEs after enable register writes.

There is a race condition between AcpiHwDisableAllGpes() or
AcpiEnableAllWakeupGpes() and AcpiEvAsynchEnableGpe() such that if the
latter wins the race, it may mistakenly enable a GPE disabled by the
former. This may lead to premature system wakeups during system suspend and
potentially to more serious consequences.

The source of the problem is how AcpiHwLowSetGpe() works when passed
ACPI_GPE_CONDITIONAL_ENABLE as the second argument. In that case, the GPE
will be enabled if the corresponding bit is set in the EnableForRun mask of
the GPE enable register containing that bit. However,
AcpiHwDisableAllGpes() and AcpiEnableAllWakeupGpes() don't modify the
EnableForRun masks of GPE registers when writing to them. In consequence,
if AcpiEvAsynchEnableGpe(), which eventually calls AcpiHwLowSetGpe() with
the second argument equal to ACPI_GPE_CONDITIONAL_ENABLE, is executed in
parallel with one of these functions, it may reverse changes made by them.

To fix the problem, introduce a new enable_mask field in
ACPI_GPE_REGISTER_INFO in which to store the current mask of enabled GPEs
and modify AcpiHwLowSetGpe() to take this mask into account instead of
EnableForRun when its second argument is equal to
ACPI_GPE_CONDITIONAL_ENABLE. Also modify the low-level routines called by
AcpiHwDisableAllGpes(), AcpiEnableAllWakeupGpes() and
AcpiEnableAllRuntimeGpes() to update the enable_mask masks of GPE registers
after all (successful) writes to those registers. Rafael J. Wysocki.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Events: Always modify GPE registers under the GPE lock.

It is reported that there are pieces of code invoking AcpiEvFinishGpe()
without holding AcpiGbl_GpeLock. Since this function will modify GPE
register values, there could be race breaking the register modification
process.

This patch fixes this issue. Lv Zheng.

Reported-by: Joe Liu <joe.liu@apple.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Acked-by: Rafael J. Wysocki <rjw@rjwysocki.net>
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 GPE
                 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>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@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
that can be used for various GPE handling models, so we need them to be
pure GPE enabling APIs. GPE enabling/disabling has 2 use cases:
1. Driver may permanently enable/disable GPEs 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. GPE need
      to be enabled for the first request submission and disabled for the
      last request completion.
   2. When the GPE is shared between 2+ silicon logics. GPE 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 GPE is enabled and it is
   disabled when the usage count is decrased from 1 to 0.
2. Driver may temporarily disables the GPE to enter an GPE polling mode and
   wants to re-enable it later.
   1. Prevent GPE storming: when a driver cannot fully solve the condition
      that triggered the GPE in the GPE context, in order not to trigger
      GPE storm, driver has to disable GPE to switch into the polling mode
      and re-enables it in the non interrupt 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 GPE handler from returning.
   3. Meet realtime requirement: in order not to block CPU to handle higher
      realtime prioritized GPEs, lower priority GPEs 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 GPE polling mode.

Note that the AcpiSetGpe()/AcpiFinishGpe() should be first introduced to
Linux using a divergence reduction patch before sending a linuxized version
of this patch. Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Events: Remove AcpiEvValidGpeEvent() due to current restriction.

Currently we rely on the logic that GPE blocks will never be deleted,
otherwise we can be broken by the race between AcpiEvCreateGpeBlock(),
AcpiEvDeleteGpeBlock() and AcpiEvGpeDetect().
On the other hand, if we want to protect GPE block creation/deletion, we
need to use a different synchronization facility to protect the period
between AcpiEvGpeDispatch() and AcpiEvAsynchEnableGpe(). Which leaves us
no choice but abandoning the ACPI_MTX_EVENTS used during this period.

This patch removes ACPI_MTX_EVENTS used during this period and the
AcpiEvValidGpeEvent() to reflect current restriction. Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Acked-by: Rafael J. Wysocki <rjw@rjwysocki.net>
Events: Cleanup of resetting the GPE handler to NULL before removing.

This patch prevents AcpiRemoveGpeHandler() from leaking the stale
GpeEventInfo->Dispatch.Handler to the caller to avoid possible NULL pointer
references. Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Events: Cleanup to move AcpiGbl_GlobalEventHandler invocation out of AcpiEvGpeDispatch().

This patch follows AcpiEvFixedEventDetect(), which invokes
AcpiGbl_GlobalEventHandler instead of invoking it in
AcpiEvFixedEventDispatch(), moves AcpiGbl_GlobalEventHandler from
AcpiEvGpeDispatch() to AcpiEvGpeDetect(). This makes further cleanups
around AcpiEvGpeDispatch() simpler. Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Events: Cleanup GPE dispatcher type obtaining code.

There is an issue in AcpiInstallGpeHandler() and AcpiRemoveGpeHandler().
The code to obtain the GPE dispatcher type from the Handler->OriginalFlags
is wrong:
    if (((Handler->OriginalFlags & ACPI_GPE_DISPATCH_METHOD) ||
         (Handler->OriginalFlags & ACPI_GPE_DISPATCH_NOTIFY)) &&
ACPI_GPE_DISPATCH_NOTIFY is 0x03 and ACPI_GPE_DISPATCH_METHOD is 0x02, thus
this statement is TRUE for the following dispatcher types:
    0x01 (ACPI_GPE_DISPATCH_HANDLER): not expected
    0x02 (ACPI_GPE_DISPATCH_METHOD): expected
    0x03 (ACPI_GPE_DISPATCH_NOTIFY): expected

There is no functional issue due to this because Handler->OriginalFlags is
only set in AcpiInstallGpeHandler(), and an earlier checker has excluded
the ACPI_GPE_DISPATCH_HANDLER:
    if ((GpeEventInfo->Flags & ACPI_GPE_DISPATCH_MASK) ==
            ACPI_GPE_DISPATCH_HANDLER)
    {
        Status = AE_ALREADY_EXISTS;
        goto FreeAndExit;
    }
    ...
    Handler->OriginalFlags = (UINT8) (GpeEventInfo->Flags &
        (ACPI_GPE_XRUPT_TYPE_MASK | ACPI_GPE_DISPATCH_MASK));

We need to clean this up before modifying the GPE dispatcher type values.

In order to prevent such issue from happening in the future, this patch
introduces ACPI_GPE_DISPATCH_TYPE() macro to be used to obtain the GPE
dispatcher types. Lv Zheng.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Events: Introduce ACPI_GPE_DISPATCH_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. Linux OSL has fixed this by flushing SCI in AcpiOsWaitEventsComplete().
We will pick up this topic when the Linux OSL fix turns out to be not
sufficient.

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_DISPATCH_RAW_HANDLER type to be distiguished from
ACPI_GPE_DISPATCH_HANDLER. For which the AcpiGbl_GpeLock is unlocked before
invoking the GPE handler and the internal enabling/disabling operations are
bypassed to allow drivers to perform them at a proper position using the
GPE APIs and ACPI_GPE_DISPATCH_RAW_HANDLER users should invoke AcpiSetGpe()
instead of AcpiEnableGpe()/AcpiDisableGpe() to bypass the internal GPE
clearing code in AcpiEnableGpe(). Lv Zheng.

Known issues:
1. Edge-triggered GPE lost for frequent enablings
   On some buggy silicon platforms, GPE enable line may not be directly
   wired to the GPE trigger line. In that case, when GPE enabling is
   frequently performed for edge-triggered GPEs, GPE status may stay set
   without being triggered.
   This patch may maginify this problem as it allows GPE enabling to be
   parallel performed during the process the GPEs are handled.
   This is an existing issue, because:
   1. For task context:
      Current ACPI_GPE_DISPATCH_METHOD practices have proven that this
      isn't a real issue - we can re-enable edge-triggered GPE in a work
      queue where the GPE status bit might already be set.
   2. For IRQ context:
      This can even happen when the GPE enabling occurs before returning
      from the GPE handler and after unlocking the GPE lock.
   Thus currently no code is included to protect this.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>