ACPI/EC: Add CPU ID to debugging messages.

This patch adds CPU ID to the context entries' debugging output. no
functional changes.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
ACPI/EC: Enhance the logs to apply to QR_EC transactions.

Currently some logs are applied to new transactions, but QR_EC transactions
are not included. This patch merges the code path to make the logs also
applying to the QR_EC transactions.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
ACPI/EC: Add detailed command/query debugging information.

Developers really don't need to translate EC commands in mind. This patch
adds detailed debugging information for the EC commands.
The address can be found in the follow-up sequential EC_DATA(W) accesses,
thus this patch also removes some of the redundant address information.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
ACPI/EC: Refine event/query debugging messages.

This patch refines event/query debugging messages to use a unified format
as commands. Developers can clearly find different processes by checking
different log seperators. No functional changes.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
ACPI/EC: Cleanup coding style.

This patch cleans up the following coding style issues that are detected by
scripts/checkpatch.pl:
 ERROR: code indent should use tabs where possible
 ERROR: "foo * bar" should be "foo *bar"
 WARNING: Missing a blank line after declarations
 WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
 WARNING: void function return statements are not generally useful
 WARNING: else is not generally useful after a break or return
 WARNING: break is not useful after a goto or return
 WARNING: braces {} are not necessary for single statement blocks
 WARNING: line over 80 characters
 WARNING: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.txt
No functional changes.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
ACPI/EC: Introduce STARTED/STOPPED flags to replace BLOCKED flag.

By using the 2 flags, we can indicate an inter-mediate state where the
current transactions should be completed while the new transactions should
be dropped.

The comparison of the old flag and the new flags:
  Old			New
  about to set BLOCKED	STOPPED set / STARTED set
  BLOCKED set		STOPPED clear / STARTED clear
  BLOCKED clear		STOPPED clear / STARTED set
The new period is between the point where we are about to set BLOCKED and
the point when the BLOCKED is set. The GPE is disabled during this period.
The new flags allow us to add acpi_ec_stopped() check to only check with
STOPPED flag to implement transaction flushing. This is not done in this
patch.

No functional changes except that after applying this patch, the GPE
enabling/disabling is protected by the EC specific lock. We can do this
because of recent ACPICA GPE API enhancement. This is reasonable as the GPE
disabling/enabling state should only be determined by the EC driver's state
machine which is protected by the EC spinlock.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
ACPI/EC: Enhance the checks to apply to QR_EC transactions.

Currently a check is applied to new transactions, but QR_EC transactions
are not included. This patch merges the code path to make the check also
applying to the QR_EC transactions.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
ACPI/EC: Add reference counting for query handlers.

This patch adds reference counting for query handlers in order to eliminate
kmalloc()/kfree() usage.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Steffen Weber <steffen.weber@gmail.com>
ACPI/EC: Cleanup command storm prevention using the new GPE handling model.

This patch deploys the following GPE handling model:
1. acpi_enable_gpe()/acpi_disable_gpe():
   This set of APIs are used for EC usage reference counting.
2. acpi_set_gpe(ACPI_GPE_ENABLE)/acpi_set_gpe(ACPI_GPE_DISABLE):
   This set of APIs are used for preventing GPE storm.
Note that this patch only converts current storm prevention implementations
using new APIs without correcting them.

For the EC driver, GPE is enabled for the following users:
1. Event monitoring (HW exception):
   If we want to query events in interrupt mode, acpi_enable_gpe() is
   invoked to allow SCI_EVT IRQs.
2. Command processing (IO request):
   When we receive an upper layer command submission, acpi_enable_gpe() is
   invoked to allow IBF=0,OBF=1 IRQs.
Comments are updated to reflect this model.

For the EC driver, GPE must be disabled for the following storms:
1. Command errors:
   If there are too many IRQs coming during a command processing period and
   such IRQs are not related to the event (SCI_EVT),
   acpi_set_gpe(ACPI_GPE_DISABLE) is invoked to prevent further storms
   during the same command transaction. This is not implemented in a good
   style. Currently once command storming is detected, it is enabled for
   all follow-up commands. Ideally, we should only enable storm prevention
   for the current command so that the next command can try the efficient
   interrupt mode again.
   This patch doesn't change current logic, the correction will be
   implemented by further patches.
2. Event errors:
   There are cases that BIOS doesn't provide a _Qxx method for the returned
   xx query value, in this case, acpi_set_gpe(ACPI_GPE_DISABLE) need to be
   invoked to prevent event IRQ storms.
   This patch doesn't implement this logic, such gap will be implemented by
   further patches.
3. Pending events:
   Though GPE is edge triggered, the underlying firmware may maliciously
   trigger GPE when IRQ is indicated. This makes EC GPE more like a level
   triggered interrupt. In case of event (SCI_EVT), since the Linux EC
   driver responses it (using QR_EC command) in the task context with GPE
   enabled, there are chances for a GPE storm to occur before QR_EC is
   executed.
   If we still want to keep the task context responding logic, for such EC
   hardware/firmware, acpi_set_gpe(ACPI_GPE_DISABLE) should be invoked
   after SCI_EVT interrupt is indicated and acpi_set_gpe(ACPI_GPE_ENABLE)
   should be invoked before the first step of QR_EC has taken place.
   This patch doesn't implement this logic, such gap can be implemented by
   future patches.

The acpi_set_gpe() should be invoked for an outstanding command,
which means it should be invoked inside of a pair of acpi_enable_gpe()/
acpi_disable_gpe() invocation. This patch thus also moves the storm
prevention logic into acpi_ec_transaction_unlocked(). Note that in order to
make it working, ACPI_REENABLE_GPE should be unset when the storming is
indicated.

The msleep(1) used after completing a transaction is kept to avoid
regressions.

Note that using the raw GPE handling model, all GPE
enabling/disabling/clearing operations should be determined by the GPE
driver's state machine, thus this patch invokes all of them with the EC
spinlock held.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
ACPI/EC: Refine command storm prevention support.

This patch refines EC command storm prevention support.

After applying the race fixes series, we almost cannot see any
in-transaction false irqs. The out-transaction false irqs are normal, they
are triggered by EC firmware for various reasons and will become silent
sooner or later. So the out-transaction false irqs are not accounted in the
original EC driver.

The EC commands are handled by different firmware processes, storming
happening to one command doesn't mean anything to another process. So
ideally, we should only enable storm prevention for the current command so
that the next command can try the efficient interrupt mode again.

This patch improves the command storm prevention by disabling GPE right
after the detection and re-enabling it right before completing the command
transaction using the GPE storming prevention APIs.

Though now we can hardly see false irqs, unit tests can be carried out by
changing the storm threshold to 0 and deleting the 2 "return wakeup"
statements from the advance_transaction(). The test result is as follows:
  ACPI : EC: ***** Command(RD_EC) started *****
  ACPI : EC: ===== TASK =====
  ACPI : EC: EC_SC(R) = 0x00 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=0
  ACPI : EC: EC_SC(W) = 0x80
  ACPI : EC: ===== IRQ =====
  ACPI : EC: EC_SC(R) = 0x00 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=0
  ACPI : EC: EC_DATA(W) = 0x23
  ACPI : EC: +++++ Polling enabled +++++
  ACPI : EC: EC_SC(R) = 0x02 SCI_EVT=0 BURST=0 CMD=0 IBF=1 OBF=0
# ACPI : EC: ===== TASK =====
  ACPI : EC: EC_SC(R) = 0x01 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=1
  ACPI : EC: EC_DATA(R) = 0x2b
  ACPI : EC: +++++ Polling disabled +++++
  ACPI : EC: ***** Command(RD_EC) stopped *****
  ACPI : EC: ===== IRQ =====
  ACPI : EC: EC_SC(R) = 0x00 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=0
  ACPI : EC: EC_SC(R) = 0x00 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=0
  ACPI : EC: EC_SC(R) = 0x00 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=0
  ACPI : EC: ***** Command(WR_EC) started *****
  ACPI : EC: ===== TASK =====
  ACPI : EC: EC_SC(R) = 0x00 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=0
  ACPI : EC: EC_SC(W) = 0x81
* ACPI : EC: ===== IRQ =====
  ACPI : EC: EC_SC(R) = 0x00 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=0
  ACPI : EC: EC_DATA(W) = 0x04
  ACPI : EC: +++++ Polling enabled +++++
  ACPI : EC: EC_SC(R) = 0x02 SCI_EVT=0 BURST=0 CMD=0 IBF=1 OBF=0
  ACPI : EC: ===== TASK =====
  ACPI : EC: EC_SC(R) = 0x00 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=0
  ACPI : EC: EC_DATA(W) = 0x01
  ACPI : EC: ===== TASK =====
  ACPI : EC: EC_SC(R) = 0x00 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=0
  ACPI : EC: +++++ Polling disabled +++++
  ACPI : EC: ***** Command(WR_EC) stopped *****
We can see the command is advanced in the task context after enabling the
polling mode (#) and the next command can still be started from the high
performance IRQ mode (*).

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
ACPI/EC: Add command flushing support.

This patch implements command flushing support. It's better to wait all
command transactions to be completed before disabling the EC GPE when the
system is going to be suspended. By doing so, the EC hardware can be
ensured to be in the idle state when the system is resumed.

There is a good indicator for flush support:
All acpi_ec_enable_gpe() is invoked after checking driver state with
acpi_ec_started() except the first one. This means all code paths can be
flushed as fast as possible by discarding the requests occurred after the
flush operation. The GPE enabling for such kind of code path is wrapped by
acpi_ec_enable_gpe_flushable().

The system suspending/resuming test result is as follows:
  ACPI : EC: +++++ Stopping EC +++++
* ACPI : EC: +++++ EC stopped +++++
  ACPI : EC: +++++ Starting EC +++++
# ACPI : EC: +++++ EC started +++++
This is performed by "switching wireless switch on/off" and "plugging power
cord in/out" frequently during the suspending/resuming. The above dmesg
shows that the EC driver is stopped during suspending (*) and is restarted
during resuming (#) correctly.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
ACPI/EC: Add a warning message to indicate event storms.

This patch splits query handler scheduling into a new seperate function
acpi_ec_notify_query_handlers() and adds a warning message in it to
indicate a BIOS bug. It is reported that EC event storm can happen in case
there is no _Qxx method prepared for the event. No functional changes.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=78091
Reported-by: Steffen Weber <steffen.weber@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
ACPI/EC: Cleanup QR_SC command processing by adding a kernel thread to poll EC events.

There is wait code in the QR_SC command processing, which makes it not
suitable to be put into a work queue item. This patch cleans up QR_SC
command processing by using an IRQ polling thread as the replacement for
the queued work item. Using thread allows us to change the EC GPE handler
into the threaded IRQ model when possible.

This poller is also useful for implementing event storm prevention. It is
reported that when the BIOS doesn't provide a _Qxx method to handle the
certain query event, the SCI_EVT interrupt can become a GPE storm hurting
the system performance (see link below, comment 55 and 80). The poller
thread thus can be used to poll SCI_EVT when storm prevention code swiches
EC driver into the polling mode.

The reasons why we do not put a loop in the event poller to poll event
until the returned query value is 0:
  Some platforms return non 0 query value even when SCI_EVT=0, if we put a
  loop in the poller, our command flush mechanism could never execute to
  an end thus the system suspending process could be blocked. One SCI_EVT
  triggering one QR_EC is current logic and has been proven to be working
  for so long time.

The reasons why it is not implemented directly using threaded IRQ are:
1. ACPICA doesn't support threaded IRQ as not all of the OSPMs support
   threaded IRQ while GPE handler registerations are done through ACPICA.
2. The IRQ processing code need to be identical for both the IRQ handler
   and the thread callback, while currently, though the command GPE
   handling is ready for both IRQ and polling mode, the event GPE is only
   handled in the polling mode.
So we use a standalone kernel thread, if the above situations are changed
in the future, we can easily convert the code into the threaded IRQ style.

The old EC_FLAGS_QUERY_PENDING is converted to EC_FLAGS_EVENT_ENABLED in
this patch, so that its naming is consistent with EC_FLAGS_EVENT_PENDING.
The original flag doesn't co-work with SCI_EVT well, this patch refines
its usage by enforcing a event polling wakeup indication as:
  EC_FLAGS_EVENT_ENABLED && EC_FLAGS_EVENT_PENDING
So unless the both of the flags are set, the threaded event poller will
not be woken up.

This patch invokes acpi_enable_gpe() after having detected SCI_EVT and
invokes acpi_disable_gpe() before having the QR_EC command processed.
This is useful for implementing GPE storm prevention for malicous "level
triggered" SCI_EVT. But the storm prevention is not implemented in this
patch.

Since the paired acpi_disable_gpe() invoked for SCI_EVT detection can only
hanppen after a QR_EC command, this patch modifies
acpi_ec_enable_gpe_flushable() to allow such QR_EC command to be proceeded
if the acpi_enable_gpe() has been invoked, which can be determined by the
event polling indication:
  EC_FLAGS_EVENT_ENABLED && EC_FLAGS_EVENT_PENDING
Without checking this reference increment for commands, QR_EC command will
not be executed to decrease the one added for SCI_EVT, thus the system
suspending will be blocked because the reference count equals to 2. Such
check is also common for flushing code.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=77431
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=78091
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=82611
Reported-by: Steffen Weber <steffen.weber@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
ACPI/EC: Add event storm prevention support.

There are cases that BIOS doesn't provide a _Qxx method for the returned
xx query value, in this case, acpi_set_gpe(ACPI_GPE_DISABLE) need to be
invoked to prevent event IRQ storms. See comment 55 and 80 in the bug link
below.

This patch implements such storm prevention using new GPE APIs.

By always enabling EC event storm prevention, we can perform a unit test,
the test shows that:
1. When EC_FLAGS_EVENT_STORM is indicated, all transactions are handled in
   the task context:
   # ACPI : EC: ===== TASK =====
     ACPI : EC: EC_SC(R) = 0x01 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=1
     ACPI : EC: EC_DATA(R) = 0x66
     ACPI : EC: ***** Command(QR_EC) stopped *****
     ACPI : EC: ##### Query(0x66) scheduled #####
     ACPI : EC: ##### Query(0x66) started #####
     ACPI : EC: ***** Command(RD_EC) started *****
   * ACPI : EC: ===== TASK =====
     ACPI : EC: EC_SC(R) = 0x00 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=0
     ACPI : EC: EC_SC(W) = 0x80
     ACPI : EC: ===== TASK =====
   * ACPI : EC: EC_SC(R) = 0x00 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=0
     ACPI : EC: EC_DATA(W) = 0x07
   * ACPI : EC: ===== TASK =====
     ACPI : EC: EC_SC(R) = 0x01 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=1
     ACPI : EC: EC_DATA(R) = 0x88
     ACPI : EC: ***** Command(RD_EC) stopped *****
   When the event storm prevention is enabled, EVT_SCI is polled in the
   task context (#), and the further commands are also handled using the
   polling mode (*) before the storming has been recovered.
2. The event poller thread will poll EVT_SCI every 5 minutes:
   [   35.233628] ACPI : EC: ***** Event poller started *****
   [   40.241432] ACPI : EC: ***** Event poller started *****
   [   45.249182] ACPI : EC: ***** Event poller started *****
   [   50.257009] ACPI : EC: ***** Event poller started *****
   [   55.264782] ACPI : EC: ***** Event poller started *****
   So the timeout facility is functioning correctly.
3. System suspend/resume test is also passed.

Note that this storm is *VERY RARE*, and we even:
1. add a threshold to prevent the event storm prevention from being false
   triggered,
2. allow recovery from first non-false query value.
So this patch doesn't affect the normal EC driver behaviors, all EC
transactions are still handled in the IRQ mode and the storming situation
can be easily recovered if the firmware doesn't maliciously trigger such
storms.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=78091
Reported-by: Steffen Weber <steffen.weber@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
ACPI/EC: Add GPE reference counting debugging messages.

This patch enhances debugging with the GPE reference count messages added.
No functional changes.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
ACPI/EC: Add support to always poll events so that GPE can be always disabled and be enabled on demand.

While the EC driver is idle, we now still have 1 reference count enabled
by EVT_SCI. By converting EVT_SCI into pure polling mode, we can have GPE
disabled all the time while still can have all IBF/OBF handled in the
interrupt mode. This patch is a demonstration of this possiblity.

An interesting test is to cat gpe file twice after switching the EC driver
into the event polling mode:
  # echo Y > /sys/module/acpi/parameters/ec_poll_events
  # cat /sys/firmware/acpi/interrupts/gpe10
      1211     !EN     !STS   disabled
  # cat /sys/firmware/acpi/interrupts/gpe10
      1238     !EN     !STS   disabled
  # dmesg | tail
  [  370.697592] ACPI : EC: EC_SC(W) = 0x80
  [  370.697716] ACPI : EC: ===== IRQ (1) =====
  [  370.697733] ACPI : EC: EC_SC(R) = 0x00 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=0
  [  370.697738] ACPI : EC: EC_DATA(W) = 0x0c
  [  370.697828] ACPI : EC: ===== IRQ (1) =====
  [  370.697838] ACPI : EC: EC_SC(R) = 0x01 SCI_EVT=0 BURST=0 CMD=0 IBF=0 OBF=1
  [  370.697849] ACPI : EC: EC_DATA(R) = 0x00
  [  370.697920] ACPI : EC: ***** Command(RD_EC) stopped *****
  [  370.697937] ACPI : EC: 0: Decrease command
  [  370.698423] ACPI : EC: ##### Query(0x66) stopped #####
  # echo N > /sys/module/acpi/parameters/ec_poll_events
  # cat /sys/firmware/acpi/interrupts/gpe10
      1271      EN     !STS   enabled
We can see GPE is disabled by the driver and disabled in the register, but
we still can see interrupt count increased because all EC commands
(including the QR_EC issued by the event poller) are still processed in the
interrupt mode.
This patch can also pass system suspend/resume test even when the EC works
in the event polling mode.

If low power SoCs are capable of taking a disabled IRQ as an indication of
a very long period LTR, then the driver running in this mode can help the
SoCs to enter a system lower power state.

And we should note that recent low power SoCs will always split IRQs like
EVT_SCI as a seperate IRQ from the FIFO IRQs. This is because of a benefit
for the client platforms:
1. Since clients doesn't need to perform listening, as EC IBF/OBF, FIFO
   IRQs are normally can be disabled while still handled in the interrupt
   mode. This can and should be done by the software.
2. But exception IRQs, as EC EVT_SCI or USB bus reset, wifi beacon, need to
   be always enabled or they will have to be polled by the software using a
   timer. Instead of using a poller to waste CPU loads, it is better to
   still enable such IRQs for the software and offload its power saving
   work to the hardware. And because such IRQs are normally high latency
   tollerance, it won't prevent the SoCs from entering lower power state
   for longer period.

Note that this facility also can be used as a quirk mechanism for the buggy
EC firmware that cannot trigger GPE for unknown reasons.

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