Commit Graph

356 Commits

Author SHA1 Message Date
Rafael J. Wysocki 3cd091a773 ACPI / EC: Restore polling during noirq suspend/resume phases
Commit 662591461c (ACPI / EC: Drop EC noirq hooks to fix a
regression) modified the ACPI EC driver so that it doesn't switch
over to busy polling mode during noirq stages of system suspend and
resume in an attempt to fix an issue resulting from that behavior.

However, that modification introduced a system resume regression on
Thinkpad X240, so make the EC driver switch over to the polling mode
during noirq stages of system suspend and resume again, which
effectively reverts the problematic commit.

Fixes: 662591461c (ACPI / EC: Drop EC noirq hooks to fix a regression)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=197863
Reported-by: Markus Demleitner <m@tfiu.de>
Tested-by: Markus Demleitner <m@tfiu.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-02-12 10:29:31 +01:00
Geert Uytterhoeven 3522f867c1 ACPI: EC: Fix debugfs_create_*() usage
acpi_ec.gpe is "unsigned long", hence treating it as "u32" would expose
the wrong half on big-endian 64-bit systems.  Fix this by changing its
type to "u32" and removing the cast, as all other code already uses u32
or sometimes even only u8.

Fixes: 1195a09816 (ACPI: Provide /sys/kernel/debug/ec/...)
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-01-04 13:54:51 +01:00
Rafael J. Wysocki b6c7026872 Merge branch 'acpi-ec' into acpi
* acpi-ec:
  ACPI / EC: Fix regression related to PM ops support in ECDT device
2017-11-30 13:37:29 +01:00
Lv Zheng a64a62ce9a ACPI / EC: Fix regression related to PM ops support in ECDT device
On platforms (ASUS X550ZE and possibly all ASUS X series) with valid ECDT
EC but invalid DSDT EC, EC PM ops won't be invoked as ECDT EC is not an
ACPI device. Thus the following commit actually removed post-resume
acpi_ec_enable_event() invocation for such platforms, and triggered a
regression on them that after being resumed, EC (actually should be ECDT)
driver stops handling EC events:

 Commit: c2b46d679b
 Subject: ACPI / EC: Add PM operations to improve event handling for resume process

Notice that the root cause actually is "ECDT is not an ACPI device" rather
than "the timing of acpi_ec_enable_event() invocation", this patch fixes
this issue by enumerating ECDT EC as an ACPI device. Due to the existence
of the noirq stage, the ability of tuning the timing of
acpi_ec_enable_event() invocation is still meaningful.

This patch is a little bit different from the posted fix by moving
acpi_config_boot_ec() from acpi_ec_ecdt_start() to acpi_ec_add() to make
sure that EC event handling won't be stopped as long as the ACPI EC driver
is bound. Thus the following sequence shouldn't disable EC event handling:
unbind,suspend,resume,bind.

Fixes: c2b46d679b (ACPI / EC: Add PM operations to improve event handling for resume process)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196847
Reported-by: Luya Tshimbalanga <luya@fedoraproject.org>
Tested-by: Luya Tshimbalanga <luya@fedoraproject.org>
Cc: 4.9+ <stable@vger.kernel.org> # 4.9+
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-11-21 00:13:02 +01:00
Linus Torvalds 1be2172e96 Modules updates for v4.15
Summary of modules changes for the 4.15 merge window:
 
 - Treewide module_param_call() cleanup, fix up set/get function
   prototype mismatches, from Kees Cook
 
 - Minor code cleanups
 
 Signed-off-by: Jessica Yu <jeyu@kernel.org>
 -----BEGIN PGP SIGNATURE-----
 
 iQIcBAABCgAGBQJaDCyzAAoJEMBFfjjOO8FyaYQP/AwHBy6XmwwVlWDP4BqIF6hL
 Vhy3ccVLYEORvePv68tWSRPUz5n6+1Ebqanmwtkw6i8l+KwxY2SfkZql09cARc33
 2iBE4bHF98iWQmnJbF6me80fedY9n5bZJNMQKEF9VozJWwTMOTQFTCfmyJRDBmk9
 iidQj6M3idbSUOYIJjvc40VGx5NyQWSr+FFfqsz1rU5iLGRGEvA3I2/CDT0oTuV6
 D4MmFxzE2Tv/vIMa2GzKJ1LGScuUfSjf93Lq9Kk0cG36qWao8l930CaXyVdE9WJv
 bkUzpf3QYv/rDX6QbAGA0cada13zd+dfBr8YhchclEAfJ+GDLjMEDu04NEmI6KUT
 5lP0Xw0xYNZQI7bkdxDMhsj5jaz/HJpXCjPCtZBnSEKiL4OPXVMe+pBHoCJ2/yFN
 6M716XpWYgUviUOdiE+chczB5p3z4FA6u2ykaM4Tlk0btZuHGxjcSWwvcIdlPmjm
 kY4AfDV6K0bfEBVguWPJicvrkx44atqT5nWbbPhDwTSavtsuRJLb3GCsHedx7K8h
 ZO47lCQFAWCtrycK1HYw+oupNC3hYWQ0SR42XRdGhL1bq26C+1sei1QhfqSgA9PQ
 7CwWH4UTOL9fhtrzSqZngYOh9sjQNFNefqQHcecNzcEjK2vjrgQZvRNWZKHSwaFs
 fbGX8juZWP4ypbK+irTB
 =c8vb
 -----END PGP SIGNATURE-----

Merge tag 'modules-for-v4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux

Pull module updates from Jessica Yu:
 "Summary of modules changes for the 4.15 merge window:

   - treewide module_param_call() cleanup, fix up set/get function
     prototype mismatches, from Kees Cook

   - minor code cleanups"

* tag 'modules-for-v4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux:
  module: Do not paper over type mismatches in module_param_call()
  treewide: Fix function prototypes for module_param_call()
  module: Prepare to convert all module_param_call() prototypes
  kernel/module: Delete an error message for a failed memory allocation in add_module_usage()
2017-11-15 13:46:33 -08:00
Lv Zheng 53c5eaabae ACPI / EC: Fix regression related to triggering source of EC event handling
Originally the Samsung quirks removed by commit 4c237371 can be covered
by commit e923e8e7 and ec_freeze_events=Y mode. But commit 9c40f956
changed ec_freeze_events=Y back to N, making this problem re-surface.

Actually, if commit e923e8e7 is robust enough, we can freely change
ec_freeze_events mode, so this patch fixes the issue by improving
commit e923e8e7.

Related commits listed in the merged order:

 Commit: e923e8e79e
 Subject: ACPI / EC: Fix an issue that SCI_EVT cannot be detected
          after event is enabled

 Commit: 4c237371f2
 Subject: ACPI / EC: Remove old CLEAR_ON_RESUME quirk

 Commit: 9c40f956ce
 Subject: Revert "ACPI / EC: Enable event freeze mode..." to fix
          a regression

This patch not only fixes the reported post-resume EC event triggering
source issue, but also fixes an unreported similar issue related to the
driver bind by adding EC event triggering source in ec_install_handlers().

Fixes: e923e8e79e (ACPI / EC: Fix an issue that SCI_EVT cannot be detected after event is enabled)
Fixes: 4c237371f2 (ACPI / EC: Remove old CLEAR_ON_RESUME quirk)
Fixes: 9c40f956ce (Revert "ACPI / EC: Enable event freeze mode..." to fix a regression)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196833
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reported-by: Alistair Hamilton <ahpatent@gmail.com>
Tested-by: Alistair Hamilton <ahpatent@gmail.com>
Cc: 4.11+ <stable@vger.kernel.org> # 4.11+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-11-09 00:23:53 +01:00
Kees Cook e4dca7b7aa treewide: Fix function prototypes for module_param_call()
Several function prototypes for the set/get functions defined by
module_param_call() have a slightly wrong argument types. This fixes
those in an effort to clean up the calls when running under type-enforced
compiler instrumentation for CFI. This is the result of running the
following semantic patch:

@match_module_param_call_function@
declarer name module_param_call;
identifier _name, _set_func, _get_func;
expression _arg, _mode;
@@

 module_param_call(_name, _set_func, _get_func, _arg, _mode);

@fix_set_prototype
 depends on match_module_param_call_function@
identifier match_module_param_call_function._set_func;
identifier _val, _param;
type _val_type, _param_type;
@@

 int _set_func(
-_val_type _val
+const char * _val
 ,
-_param_type _param
+const struct kernel_param * _param
 ) { ... }

@fix_get_prototype
 depends on match_module_param_call_function@
identifier match_module_param_call_function._get_func;
identifier _val, _param;
type _val_type, _param_type;
@@

 int _get_func(
-_val_type _val
+char * _val
 ,
-_param_type _param
+const struct kernel_param * _param
 ) { ... }

Two additional by-hand changes are included for places where the above
Coccinelle script didn't notice them:

	drivers/platform/x86/thinkpad_acpi.c
	fs/lockd/svc.c

Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jessica Yu <jeyu@kernel.org>
2017-10-31 15:30:37 +01:00
Christoph Hellwig 6faadbbb7f dmi: Mark all struct dmi_system_id instances const
... and __initconst if applicable.

Based on similar work for an older kernel in the Grsecurity patch.

[JD: fix toshiba-wmi build]
[JD: add htcpen]
[JD: move __initconst where checkscript wants it]

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jean Delvare <jdelvare@suse.de>
2017-09-14 11:59:30 +02:00
Lv Zheng 56f77eeb6b ACPI / EC: Clean up EC GPE mask flag
EC_FLAGS_COMMAND_STORM is actually used to mask GPE during IRQ processing.
This patch cleans it up using more readable flag/function names.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Tomislav Ivek <tomislav.ivek@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-19 18:12:04 +02:00
Lv Zheng 69b957c26b ACPI: EC: Fix possible issues related to EC initialization order
Use the observation that the EC command/data register addresses are
sufficient to determine if two EC devices are equivelent to modify
acpi_is_boot_ec().

Then, for the removed comparison factors, EC ID and EC GPE, they need
to be synchronized for the boot_ec:

 1. Before registering the BIOS-provided EC event handlers in
    acpi_ec_register_query_methods(), the namespace node holding
    _Qxx methods should be located.  The real namespace PNP0C09
    device location then is apparently more trustworthy than the
    ECDT EC ID.

 2. Because of the ASUS quirks, the ECDT EC GPE is more trustworthy
    than the namespace PNP0C09 device's _GPE setting.

Use the above observations to synchronize the boot_ec settings in
acpi_ec_add().

Finally, change the order of acpi_ec_ecdt_start() and acpi_ec_add(),
called from acpi_bus_register_driver(), so as to follow the fast path
of determining the location of _Qxx.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
[ rjw : Changelog & comments ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-18 15:12:10 +02:00
Lv Zheng 98529b9272 ACPI: EC: Fix regression related to wrong ECDT initialization order
Commit 2a5708409e (ACPI / EC: Fix a gap that ECDT EC cannot handle
EC events) introduced acpi_ec_ecdt_start(), but that function is
invoked before acpi_ec_query_init(), which is too early.  This causes
the kernel to crash if an EC event occurs after boot, when ec_query_wq
is not valid:

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000102
 ...
 Workqueue: events acpi_ec_event_handler
 task: ffff9f539790dac0 task.stack: ffffb437c0e10000
 RIP: 0010:__queue_work+0x32/0x430

Normally, the DSDT EC should always be valid, so acpi_ec_ecdt_start()
is actually a no-op in the majority of cases.  However, commit
c712bb58d8 (ACPI / EC: Add support to skip boot stage DSDT probe)
caused the probing of the DSDT EC as the "boot EC" to be skipped when
the ECDT EC is valid and uncovered the bug.

Fix this issue by invoking acpi_ec_ecdt_start() after acpi_ec_query_init()
in acpi_ec_init().

Link: https://jira01.devtools.intel.com/browse/LCK-4348
Fixes: 2a5708409e (ACPI / EC: Fix a gap that ECDT EC cannot handle EC events)
Fixes: c712bb58d8 (ACPI / EC: Add support to skip boot stage DSDT probe)
Reported-by: Wang Wendy <wendy.wang@intel.com>
Tested-by: Feng Chenzhou <chenzhoux.feng@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-17 20:52:19 +02:00
Rafael J. Wysocki 880a66275e ACPI / PM / EC: Flush all EC work in acpi_freeze_sync()
Commit eed4d47efe (ACPI / sleep: Ignore spurious SCI wakeups from
suspend-to-idle) introduced acpi_freeze_sync() whose purpose is to
flush all of the processing of possible wakeup events signaled via
the ACPI SCI.  However, it doesn't flush the query workqueue used
by the EC driver, so the events generated by the EC may not be
processed timely which leads to issues (increased overhead at least,
lost events possibly).

To fix that introduce acpi_ec_flush_work() that will flush all of
the outstanding EC work and call it from acpi_freeze_sync().

Fixes: eed4d47efe (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-20 16:44:24 +02:00
Rafael J. Wysocki 6ed8600529 Merge branch 'acpi-ec' into acpi-pm 2017-07-20 16:44:09 +02:00
Rafael J. Wysocki 7638063628 ACPI / EC: Add parameter to force disable the GPE on suspend
After commit 8110dd281e (ACPI / sleep: EC-based wakeup from
suspend-to-idle on recent systems) the configuration of GPEs,
including the EC one, is not changed during suspend-to-idle on
recent systems.  That's in order to make system wakeup events
generated by the EC work, in particular.

However, on some of the systems in question (for example on Dell
XPS13 9365), in addition to generating system wakeup events the
EC generates a heartbeat sequence of interrupts that have nothing
to do with wakeup while suspended, and the Low Power Idle S0 _DSM
interface doesn't change that behavior.

The users of those systems may prefer to disable the EC GPE during
system suspend, for the cost of non-functional power button wakeup
or similar, but currently there is no way to do that.

For this reason, add a new module parameter, ec_no_wakeup, for the
EC driver module that, if set, will cause the EC GPE to be disabled
during system suspend and re-enabled during the subsequent system
resume.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=192591#c106
Amends: 8110dd281e (ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems)
Reported-and-tested-by: Patrik Kullman <patrik.kullman@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-19 14:41:58 +02:00
Rafael J. Wysocki 9636603da3 Merge branches 'acpi-ec', 'acpi-irq' and 'acpi-quirks'
* acpi-ec:
  Revert "ACPI / EC: Enable event freeze mode..." to fix a regression
  ACPI / EC: Drop EC noirq hooks to fix a regression

* acpi-irq:
  ACPI / irq: Fix return code of acpi_gsi_to_irq()

* acpi-quirks:
  ACPI / x86: Add KIOX000A accelerometer on GPD win to always_present_ids array
  ACPI / x86: Add Dell Venue 11 Pro 7130 touchscreen to always_present_ids
  ACPI / x86: Allow matching always_present_id array entries by DMI
2017-07-14 13:17:53 +02:00
Lv Zheng 9c40f956ce Revert "ACPI / EC: Enable event freeze mode..." to fix a regression
On Lenovo ThinkPad X1 Carbon - the 5th Generation, enabling an earlier
EC event freezing timing causes acpitz-virtual-0 to report a stuck
48C temparature.  And with EC firmware revisioned as 1.14, without
reverting back to old EC event freezing timing, the fan still blows
up after a system resume.

This reverts the culprit change so that the regression can be fixed
without upgrading the EC firmware.

Fixes: d30283057e (ACPI / EC: Enable event freeze mode to improve event handling)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=191181#c168
Tested-by: Damjan Georgievski <gdamjan@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: 4.9+ <stable@vger.kernel.org> # 4.9+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-12 13:20:17 +02:00
Lv Zheng 662591461c ACPI / EC: Drop EC noirq hooks to fix a regression
According to bug reports, although the busy polling mode can make
noirq stages execute faster, it causes abnormal fan blowing up after
system resume (see the first link below for a video demonstration)
on Lenovo ThinkPad X1 Carbon - the 5th Generation.  The problem can
be fixed by upgrading the EC firmware on that machine.

However, many reporters confirm that the problem can be fixed by
stopping busy polling during suspend/resume and for some of them
upgrading the EC firmware is not an option.

For this reason, drop the noirq stage hooks from the EC driver
to fix the regression.

Fixes: c3a696b6e8 (ACPI / EC: Use busy polling mode when GPE is not enabled)
Link: https://youtu.be/9NQ9x-Jm99Q
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196129
Reported-by: Andreas Lindhe <andreas@lindhe.io>
Tested-by: Gjorgji Jankovski <j.gjorgji@gmail.com>
Tested-by: Damjan Georgievski <gdamjan@gmail.com>
Tested-by: Fernando Chaves <nanochaves@gmail.com>
Tested-by: Tomislav Ivek <tomislav.ivek@gmail.com>
Tested-by: Denis P. <theoriginal.skullburner@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-12 13:20:17 +02:00
Linus Torvalds eceeae414e ACPI updates for v4.13-rc1
- Update the ACPICA code in the kernel to upstream revision
    revision 20170531 (which covers all of the new material from
    ACPI 6.2) including:
    * Support for the PinFunction(), PinConfig(), PinGroup(),
      PinGroupFunction(), and PinGroupConfig() resource descriptors
      (Mika Westerberg).
    * Support for new subtables in HEST and SRAT, new notify value
      for HEST, header support for TPM2 table changes, and BGRT
      Status field update (Bob Moore).
    * Support for new PCCT subtables (David Box).
    * Support for _LSI, _LSR, _LSW, and _HMA as predefined methods
      (Erik Schmauss).
    * Support for the new WSMT, HMAT, and PPTT tables (Lv Zheng).
    * New UUID values for Processor Properties (Bob Moore).
    * New notify values for memory attributes and graceful shutdown
      (Bob Moore).
    * Fix related to the PCAT_COMPAT MADT flag (Janosch Hildebrand).
    * Resource to AML conversion fix for resources containing GPIOs
      (Mika Westerberg).
    * Disassembler-related updates (Bob Moore, David Box, Erik
      Schmauss).
    * Assorted fixes and cleanups (Bob Moore, Erik Schmauss, Lv Zheng,
      Cao Jin).
 
  - Modify ACPICA to always use designated initializers for function
    pointer structures to make the structure layout randomization GCC
    plugin work with it (Kees Cook).
 
  - Update the tables configfs interface to unload SSDTs on configfs
    entry removal (Jan Kiszka).
 
  - Add support for the GPI1 regulator to the xpower PMIC Operation
    Region handler (Hans de Goede).
 
  - Fix ACPI EC issues related to conflicting EC definitions in the
    ECDT and in the ACPI namespace (Lv Zheng, Carlo Caione, Chris
    Chiu).
 
  - Fix an interrupt storm issue in the EC driver and make its debug
    output work with dynamic debug as expected (Lv Zheng).
 
  - Add ACPI backlight quirk for Dell Precision 7510 (Shih-Yuan Lee).
 
  - Fix whitespace in pr_fmt() to align log entries properly in some
    places in the ACPI subsystem (Vincent Legoll).
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQIcBAABCAAGBQJZWrJyAAoJEILEb/54YlRxY2cP/1h2un46sEnP7uLVLK4lpEih
 NQ79+fA7NTidA9J6gin2Kjgl8BFgswAhQBJZG3cJxUrhIIRWItSeLGvHb0CXX+iY
 m7CpL0ralIKV9XCju8B5b2V+0qn2tPzHS5a8PSX9Gvs0N6G8Qnlq4jspIjXMa3zH
 3D/fmYbQZeuHjypiBqRlB5IE49O2FQL2+d4Vn1rryuAFFya610ulASOZxsQ015d4
 Xt2pSTqUbqeD8rG8+j4VKFy8x0Lj0eEU3FUgYNJHlO+pOG+wTTs3KPyNOa33h0OC
 US0Wc0XOUyz78P5YkEgA7Ve/j1E6bqQ9bVF6mIcqjvAOReqSe84RCJ86Ckjlewxf
 VMNjCT/qDDkB8d+IAX6e7uYwxuP8bTSfUGBHjoI16qaJ13zd1/jOVY8QH5zPg5Ml
 r06HO5iOrQS3yhumYRk3gIdV+cgdHt3SEQlfi30nFH5Yzp8epk85UPyjYUYPDwqy
 QP5QbYvmHyuIUSXW2HQxZYADSaqnKIglRizCIKcFHT5+J554DjM5T51A5UpyQkY3
 cjtgrpg4KA5qCrpUAqPPxA2mtUVsZk1h4HwhrkTVt4xaR9GP9gvvzonP552fmHrM
 nIX9tM2JEf+LC7eCV+yrk8dtGNTRYpmEBQw7go4R82pTE5YTOWDf1bNM59gTFoWP
 LXi28C9lb2aibWlX/0bw
 =ImFw
 -----END PGP SIGNATURE-----

Merge tag 'acpi-4.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

Pull ACPI updates from Rafael Wysocki:
 "These mostly update the ACPICA code in the kernel to upstream revision
  20170531 which covers all of the new material from ACPI 6.2, including
  new tables (WSMT, HMAT, PPTT), new subtables and definition changes
  for some existing tables (BGRT, HEST, SRAT, TPM2, PCCT), new resource
  descriptor macros for pin control, support for new predefined methods
  (_LSI, _LSR, _LSW, _HMA), fixes and cleanups.

  On top of that, an additional ACPICA change from Kees (which also is
  upstream already) switches all of the definitions of function pointer
  structures in ACPICA to use designated initializers so as to make the
  structure layout randomization GCC plugin work with it.

  The rest is a few fixes and cleanups in the EC driver, an xpower PMIC
  driver update, a new backlight blacklist entry, and update of the
  tables configfs interface and a messages formatting cleanup.

  Specifics:

   - Update the ACPICA code in the kernel to upstream revision revision
     20170531 (which covers all of the new material from ACPI 6.2)
     including:
      * Support for the PinFunction(), PinConfig(), PinGroup(),
        PinGroupFunction(), and PinGroupConfig() resource descriptors
        (Mika Westerberg).
      * Support for new subtables in HEST and SRAT, new notify value for
        HEST, header support for TPM2 table changes, and BGRT Status
        field update (Bob Moore).
      * Support for new PCCT subtables (David Box).
      * Support for _LSI, _LSR, _LSW, and _HMA as predefined methods
        (Erik Schmauss).
      * Support for the new WSMT, HMAT, and PPTT tables (Lv Zheng).
      * New UUID values for Processor Properties (Bob Moore).
      * New notify values for memory attributes and graceful shutdown
        (Bob Moore).
      * Fix related to the PCAT_COMPAT MADT flag (Janosch Hildebrand).
      * Resource to AML conversion fix for resources containing GPIOs
        (Mika Westerberg).
      * Disassembler-related updates (Bob Moore, David Box, Erik
        Schmauss).
      * Assorted fixes and cleanups (Bob Moore, Erik Schmauss, Lv Zheng,
        Cao Jin).

   - Modify ACPICA to always use designated initializers for function
     pointer structures to make the structure layout randomization GCC
     plugin work with it (Kees Cook).

   - Update the tables configfs interface to unload SSDTs on configfs
     entry removal (Jan Kiszka).

   - Add support for the GPI1 regulator to the xpower PMIC Operation
     Region handler (Hans de Goede).

   - Fix ACPI EC issues related to conflicting EC definitions in the
     ECDT and in the ACPI namespace (Lv Zheng, Carlo Caione, Chris
     Chiu).

   - Fix an interrupt storm issue in the EC driver and make its debug
     output work with dynamic debug as expected (Lv Zheng).

   - Add ACPI backlight quirk for Dell Precision 7510 (Shih-Yuan Lee).

   - Fix whitespace in pr_fmt() to align log entries properly in some
     places in the ACPI subsystem (Vincent Legoll)"

* tag 'acpi-4.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (63 commits)
  ACPI / EC: Add quirk for GL720VMK
  ACPI / EC: Fix media keys not working problem on some Asus laptops
  ACPI / EC: Add support to skip boot stage DSDT probe
  ACPI / EC: Enhance boot EC sanity check
  ACPI / video: Add quirks for the Dell Precision 7510
  ACPI: EC: Fix EC command visibility for dynamic debug
  ACPI: EC: Fix an EC event IRQ storming issue
  ACPICA: Use designated initializers
  ACPICA: Update version to 20170531
  ACPICA: Update a couple of debug output messages
  ACPICA: acpiexec: enhance local signal handler
  ACPICA: Simplify output for the ACPI Debug Object
  ACPICA: Unix application OSL: Correctly handle control-c (EINTR)
  ACPICA: Improvements for debug output only
  ACPICA: Disassembler: allow conflicting external declarations to be emitted.
  ACPICA: Disassembler: add external op to namespace on first pass
  ACPICA: Disassembler: prevent external op's from opening a new scope
  ACPICA: Changed Gbl_disasm_flag to acpi_gbl_disasm_flag
  ACPICA: Changing External to a named object
  ACPICA: Update two error messages to emit control method name
  ...
2017-07-04 14:16:49 -07:00
Rafael J. Wysocki 03471c06d0 Merge branches 'acpi-ec' and 'acpi-video'
* acpi-ec:
  ACPI / EC: Add quirk for GL720VMK
  ACPI / EC: Fix media keys not working problem on some Asus laptops
  ACPI / EC: Add support to skip boot stage DSDT probe
  ACPI / EC: Enhance boot EC sanity check
  ACPI: EC: Fix EC command visibility for dynamic debug
  ACPI: EC: Fix an EC event IRQ storming issue

* acpi-video:
  ACPI / video: Add quirks for the Dell Precision 7510
2017-07-03 14:26:43 +02:00
Carlo Caione ef75040ab7 ACPI / EC: Add quirk for GL720VMK
ASUS GL720VMK is also affected by the EC GPE preference issue.

Signed-off-by: Carlo Caione <carlo@caione.org>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-29 00:00:01 +02:00
Chris Chiu 440f53da70 ACPI / EC: Fix media keys not working problem on some Asus laptops
Some Asus laptops (verified on X550VXK/FX502VD/FX502VE) get no
interrupts when pressing media keys thus the corresponding functions
are not invoked. It's due to the _GPE defines in DSDT for EC returns
differnt value compared to the GPE Number in ECDT. Confirmed with Asus
that the vale in ECDT is the correct one. This commit uses DMI quirks
to prevent calling _GPE when doing ec_parse_device() and keep the ECDT
GPE number setting for the EC device.

With previous commit, it is ensured that if there is an ECDT, it can
always be kept as boot_ec, this patch thus can implement a quirk on
top of the determined ECDT boot_ec.

Link: https://phabricator.endlessm.com/T16033
Link: https://phabricator.endlessm.com/T16722
Link: https://bugzilla.kernel.org/show_bug.cgi?id=195651
Tested-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Carlo Caione <carlo@caione.org>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-29 00:00:01 +02:00
Lv Zheng c712bb58d8 ACPI / EC: Add support to skip boot stage DSDT probe
We prepared _INI/_STA methods for \_SB, \_SB.PCI0, \_SB.LID0 and
\_SB.EC, _HID(PNP0C09)/_CRS/_GPE for \_SB.EC to poke Windows behavior
with qemu, we got the following execution sequence:

 \_SB._INI
 \_SB.PCI0._STA
 \_SB.LID0._STA
 \_SB.EC._STA
 \_SB.PCI0._INI
 \_SB.LID0._INI
 \_SB.EC._INI

There is no extra DSDT EC device enumeration process occurring before
the main ACPI device enumeration process. That means acpi_ec_dsdt_probe()
is not Windows-compatible.

Tracking back, it was added by the following commit:

  Commit: c5279dee26
  Subject: ACPI: EC: Add some basic check for ECDT data

but that commit was misguided.

Why we shouldn't enumerate DSDT EC before the main ACPI device
enumeration?

The only way to know if the DSDT EC is valid would be to evaluate its
_STA control method, but it's not safe to evaluate this control method
that early and out of the ACPI enumeration process, because _STA may
refer to entities (such as resources or ACPI device objects) that may
not have been initialized before OSPM starts to enumerate them via
the main ACPI device enumeration.

But after we had reverted back to the expected behavior, a regression
was reported.  On that platform, there is no ECDT, but the platform
control methods access EC operation region earlier than Linux expects
causing some ACPI method execution errors. For this reason, we just
go back to old behavior to still probe DSDT EC as the boot EC.

However, that turns out to lead to yet another functional breakage
and in order to work around all of the problems, we skip boot stage
DSDT probe when the ECDT exists so that a later quirk can always use
correct ECDT GPE setting.

Link: http://bugzilla.kernel.org/show_bug.cgi?id=11880
Link: http://bugzilla.kernel.org/show_bug.cgi?id=119261
Link: http://bugzilla.kernel.org/show_bug.cgi?id=195651
Tested-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
[ rjw: Changelog & comments massage ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-29 00:00:01 +02:00
Lv Zheng ae56c9fd15 ACPI / EC: Enhance boot EC sanity check
It's reported that some buggy BIOS tables can contain 2 DSDT ECs, one of
them is invalid but acpi_ec_dsdt_probe() fails to pick the valid one.
This patch simply enhances sanity checks in ec_parse_device() as a
workaround to skip probing wrong namespace ECs.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=195651
Tested-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-29 00:00:01 +02:00
Lv Zheng 4625d752e6 ACPI: EC: Fix EC command visibility for dynamic debug
acpi_ec_cmd_string() currently is only enabled for "DEBUG" macro, but users
trend to use CONFIG_DYNAMIC_DEBUG and enable ec.c pr_debug() print-outs by
"dyndbg='file ec.c +p'". In this use case, all command names are turned
into UNDEF and the log is confusing. This affects bugzilla triage work.

This patch fixes this issue by enabling acpi_ec_cmd_string() for
CONFIG_DYNAMIC_DEBUG.

Tested-by: Wang Wendy <wendy.wang@intel.com>
Tested-by: Feng Chenzhou <chenzhoux.feng@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-28 02:28:22 +02:00
Lv Zheng 1ab69f27cb ACPI: EC: Fix an EC event IRQ storming issue
The EC event IRQ (SCI_EVT) can only be handled by submitting QR_EC. As the
EC driver handles SCI_EVT in a workqueue, after SCI_EVT is flagged and
before QR_EC is submitted, there is a period risking IRQ storming. EC IRQ
must be masked for this period but linux EC driver never does so.

No end user notices the IRQ storming and no developer fixes this known
issue because:

 1. The EC IRQ is always edge triggered GPE, and
 2. The kernel can execute no-op EC IRQ handler very fast.

For edge-triggered EC GPE platforms, it is only reported of post-resume EC
event lost issues, there won't be an IRQ storming. For level triggered EC
GPE platforms, fortunately the kernel is always fast enough to execute such
a no-op EC IRQ handler so that the IRQ handler won't be accumulated to
starve the task contexts, causing a real IRQ storming.

But the IRQ storming actually can still happen when:

 1. The EC IRQ performs like level triggered GPE, and
 2. The kernel EC debugging log is turned on but the console is slow enough.

There are more and more platforms using EC GPE as wake GPE where the EC GPE
is likely designed as level triggered. Then when EC debugging log is
enabled, the EC IRQ handler is no longer a no-op but dumps IRQ status to
the consoles. If the consoles are slow enough, the EC IRQs can arrive much
faster than executing the handler. Finally the accumulated EC event IRQ
handlers starve the task contexts, causing the IRQ storming to occur, and
the kernel hangs can be observed during boot/resume.

This patch fixes this issue by masking EC IRQ for this period:

 1. Begins when there is an SCI_EVT IRQ pending, and
 2. Ends when there is a QR_EC completed (SCI_EVT acknowledged).

Tested-by: Wang Wendy <wendy.wang@intel.com>
Tested-by: Feng Chenzhou <chenzhoux.feng@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-28 02:28:21 +02:00
Rafael J. Wysocki 8110dd281e ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems
Some recent Dell laptops, including the XPS13 model numbers 9360 and
9365, cannot be woken up from suspend-to-idle by pressing the power
button which is unexpected and makes that feature less usable on
those systems.  Moreover, on the 9365 ACPI S3 (suspend-to-RAM) is
not expected to be used at all (the OS these systems ship with never
exercises the ACPI S3 path in the firmware) and suspend-to-idle is
the only viable system suspend mechanism there.

The reason why the power button wakeup from suspend-to-idle doesn't
work on those systems is because their power button events are
signaled by the EC (Embedded Controller), whose GPE (General Purpose
Event) line is disabled during suspend-to-idle transitions in Linux.
That is done on purpose, because in general the EC tends to be noisy
for various reasons (battery and thermal updates and similar, for
example) and all events signaled by it would kick the CPUs out of
deep idle states while in suspend-to-idle, which effectively might
defeat its purpose.

Of course, on the Dell systems in question the EC GPE must be enabled
during suspend-to-idle transitions for the button press events to
be signaled while suspended at all, but fortunately there is a way
out of this puzzle.

First of all, those systems have the ACPI_FADT_LOW_POWER_S0 flag set
in their ACPI tables, which means that the OS is expected to prefer
the "low power S0 idle" system state over ACPI S3 on them.  That
causes the most recent versions of other OSes to simply ignore ACPI
S3 on those systems, so it is reasonable to expect that it should not
be necessary to block GPEs during suspend-to-idle on them.

Second, in addition to that, the systems in question provide a special
firmware interface that can be used to indicate to the platform that
the OS is transitioning into a system-wide low-power state in which
certain types of activity are not desirable or that it is leaving
such a state and that (in principle) should allow the platform to
adjust its operation mode accordingly.

That interface is a special _DSM object under a System Power
Management Controller device (PNP0D80).  The expected way to use it
is to invoke function 0 from it on system initialization, functions
3 and 5 during suspend transitions and functions 4 and 6 during
resume transitions (to reverse the actions carried out by the
former).  In particular, function 5 from the "Low-Power S0" device
_DSM is expected to cause the platform to put itself into a low-power
operation mode which should include making the EC less verbose (so to
speak).  Next, on resume, function 6 switches the platform back to
the "working-state" operation mode.

In accordance with the above, modify the ACPI suspend-to-idle code
to look for the "Low-Power S0" _DSM interface on platforms with the
ACPI_FADT_LOW_POWER_S0 flag set in the ACPI tables.  If it's there,
use it during suspend-to-idle transitions as prescribed and avoid
changing the GPE configuration in that case.  [That should reflect
what the most recent versions of other OSes do.]

Also modify the ACPI EC driver to make it handle events during
suspend-to-idle in the usual way if the "Low-Power S0" _DSM interface
is going to be used to make the power button events work while
suspended on the Dell machines mentioned above

Link: http://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-23 15:24:32 +02:00
Vincent Legoll b6aeab44ed ACPI: fix whitespace in pr_fmt() to align log entries
See this dmesg extract before the patch:

[    0.679466] ACPI: Dynamic OEM Table Load:
[    0.679470] ACPI: SSDT 0xFFFF910F6B497E00 00018A (v02 PmRef  ApCst    00003000 INTL 20160422)
[    0.679579] ACPI: Executed 1 blocks of module-level executable AML code
[    0.681477] ACPI : EC: EC started
[    0.681478] ACPI : EC: interrupt blocked
[    0.684798] ACPI: Interpreter enabled
[    0.684835] ACPI: (supports S0 S3 S4 S5)

Signed-off-by: Vincent Legoll <vincent.legoll@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-22 02:18:20 +02:00
Lv Zheng c3a696b6e8 ACPI / EC: Use busy polling mode when GPE is not enabled
When GPE is not enabled, it is not efficient to use the wait polling mode
as it introduces an unexpected scheduler delay.
So before the GPE handler is installed, this patch uses busy polling mode
for all EC(s) and the logic can be applied to non boot EC(s) during the
suspend/resume process.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=191561
Tested-by: Jakobus Schurz <jakobus.schurz@gmail.com>
Tested-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-01-30 12:12:52 +01:00
Lv Zheng 4c237371f2 ACPI / EC: Remove old CLEAR_ON_RESUME quirk
IRQ polling logic has been implemented to drain the post-boot/resume
EC events:

 1. Triggered by the following code, invoked from acpi_ec_enable_event():

	if (!test_bit(EC_FLAGS_QUERY_PENDING, &ec->flags))
		advance_transaction(ec);

 2. Drained by the following code, invoked after acpi_ec_complete_query():

	if (status & ACPI_EC_FLAG_SCI)
		acpi_ec_submit_query(ec);

This facility is safer than the old CLEAR_ON_RESUME quirk as the
CLEAR_ON_RESUME quirk sends EC query commands unconditionally. The
behavior is apparently not suitable for firmware that requires
QUERY_HANDSHAKE quirk. Though the QUERY_HANDSHAKE quirk isn't used
now because of the improvement done in the EC transaction state
machine (ec_event_clearing=QUERY), it is the proof that we cannot
send EC query command unconditionally.

So it's time to delete the out-dated CLEAR_ON_RESUME quirk to let the
users to try the newer approach.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=191211
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-01-30 12:12:03 +01:00
Eric Biggers eab05ec380 ACPI / EC: Fix unused function warning when CONFIG_PM_SLEEP=n
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-10-10 02:22:20 +02:00
Lv Zheng 97cb159fd9 ACPI / EC: Fix issues related to boot_ec
There are issues related to the boot_ec:
1. If acpi_ec_remove() is invoked, boot_ec will also be freed, this is not
   expected as the boot_ec could be enumerated via ECDT.
2. Address space handler installation/unstallation lead to unexpected _REG
   evaluations.
This patch adds acpi_is_boot_ec() check to be used to fix the above issues.
However, since acpi_ec_remove() actually won't be invoked, this patch
doesn't handle the reference counting of "struct acpi_ec", it only ensures
the correctness of the boot_ec destruction during the boot.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=153511
Reported-and-tested-by: Jonh Henderson <jw.hendy@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-10 02:33:50 +02:00
Lv Zheng 2a5708409e ACPI / EC: Fix a gap that ECDT EC cannot handle EC events
It is possible to register _Qxx from namespace and use the ECDT EC to
perform event handling. The reported bug reveals that Windows is using ECDT
in this way in case the namespace EC is not present. This patch facilitates
Linux to support ECDT in this way.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=115021
Reported-and-tested-by: Luya Tshimbalanga <luya@fedoraproject.org>
Tested-by: Jonh Henderson <jw.hendy@gmail.com>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-10 02:33:50 +02:00
Lv Zheng 46922d2a3a ACPI / EC: Fix a memory leakage issue in acpi_ec_add()
When the handler installation failed, there was no code to free the
allocated EC device. This patch fixes this memory leakage issue.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=115021
Reported-and-tested-by: Luya Tshimbalanga <luya@fedoraproject.org>
Tested-by: Jonh Henderson <jw.hendy@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-10 02:33:49 +02:00
Lv Zheng 72c77b7ea9 ACPI / EC: Cleanup first_ec/boot_ec code
In order to support full ECDT (driving the ECDT EC after probing the
namespace EC), we need to change our EC device alloc/free algorithm, ensure
not to free old boot EC before qualifying new boot EC.
This patch achieves this by cleaning up first_ec/boot_ec logic:
1. first_ec: used to perform transactions, so it is assigned in new
   acpi_ec_setup() function.
2. boot_ec: used to track early EC device, so it is assigned in new
   acpi_config_boot_ec() function which explictly tells the driver to save
   the EC device as early EC device.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=115021
Reported-and-tested-by: Luya Tshimbalanga <luya@fedoraproject.org>
Tested-by: Jonh Henderson <jw.hendy@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-10 02:33:49 +02:00
Lv Zheng d30283057e ACPI / EC: Enable event freeze mode to improve event handling for suspend process
This patch enables the event freeze mode, flushing the EC event handling in
.suspend() callback. This feature is experimental, if it is bisected out to
be the cause of the real issues, please report the issues to the kernel
bugzilla for further root causing and improvement.

This mode eliminates useless _Qxx handling during the power saving
operations, thus can help to tune the power saving operations faster. Tests
show that this mode can efficiently block flooding _Qxx during the suspend
process and tune the speed of the suspend faster.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Todd E Brandt <todd.e.brandt@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-31 00:32:11 +02:00
Lv Zheng 39a2a2aa3e ACPI / EC: Add PM operations to improve event handling for suspend process
In the original EC driver, though the event handling is not explicitly
stopped, the EC driver is actually not able to handle events during the
noirq stage as the EC driver is not prepared to handle the EC events in the
polling mode. So if there is no advance_transaction() triggered, the EC
driver couldn't notice the EC events.
However, do we actually need to handle EC events during suspend/resume
stage? EC events are mostly useless for the suspend/resume period (key
strokes and battery/thermal updates, etc.,), and the useful ones (lid
close, power/sleep button press) should have already been delivered to the
OSPM to trigger the power saving operations.
Thus this patch implements acpi_ec_disable_event() to be a reverse call of
acpi_ec_enable_event(), with which, the EC driver is able to stop handling
the EC events in a position before entering the noirq stage.

Since there are actually 2 choices for us:
1. implement event handling in polling mode;
2. stop event handling before entering noirq stage.
And this patch only implements the second choice using .suspend() callback.
Thus this is experimental (first choice is better? or different hook
position is better?). This patch finally keeps the old behavior by default
and prepares a boot parameter to enable this feature.

The differences of the event handling availability between the old behavior
(this patch is not applied) and the new behavior (this patch is applied)
are as follows:
                        !FreezeEvents   FreezeEvents
before suspend          Y               Y
suspend before EC       Y               Y
suspend after EC        Y               N
suspend_late            Y               N
suspend_noirq           Y (actually N)  N
resume_noirq            Y (actually N)  N
resume_late             Y (actually N)  N
resume before EC        Y (actually N)  N
resume after EC         Y               Y
after resume            Y               Y
Where "actually N" means if there is no EC transactions, the EC driver
is actually not able to notice the pending events.

We can see that FreezeEvents is the only approach now can actually flush
the EC event handling with both query commands and _Qxx evaluations
flushed, other modes can only flush the EC event handling with only query
commands flushed, _Qxx evaluations occurred after stopping the EC driver
may end up failure due to the failure of the EC transaction carried out in
the _Qxx control methods.

We also can see that this feature should be able to trigger some platform
notifications later than resuming other drivers.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Todd E Brandt <todd.e.brandt@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-31 00:32:11 +02:00
Lv Zheng c2b46d679b ACPI / EC: Add PM operations to improve event handling for resume process
This patch makes 2 changes:

1. Restore old behavior
Originally, EC driver stops handling both events and transactions in
acpi_ec_block_transactions(), and restarts to handle transactions in
acpi_ec_unblock_transactions_early(), restarts to handle both events and
transactions in acpi_ec_unblock_transactions().
While currently, EC driver still stops handling both events and
transactions in acpi_ec_block_transactions(), but restarts to handle both
events and transactions in acpi_ec_unblock_transactions_early().
This patch tries to restore the old behavior by dropping
__acpi_ec_enable_event() from acpi_unblock_transactions_early().

2. Improve old behavior
However this still cannot fix the real issue as both of the
acpi_ec_unblock_xxx() functions are invoked in the noirq stage. Since the
EC driver actually doesn't implement the event handling in the polling
mode, re-enabling the event handling too early in the noirq stage could
result in the problem that if there is no triggering source causing
advance_transaction() to be invoked, pending SCI_EVT cannot be detected by
the EC driver and _Qxx cannot be triggered.
It actually makes sense to restart the event handling in any point during
resuming after the noirq stage. Just like the boot stage where the event
handling is enabled in .add(), this patch further moves
acpi_ec_enable_event() to .resume(). After doing that, the following 2
functions can be combined:
acpi_ec_unblock_transactions_early()/acpi_ec_unblock_transactions().

The differences of the event handling availability between the old behavior
(this patch isn't applied) and the new behavior (this patch is applied) are
as follows:
                        !Applied        Applied
before suspend          Y               Y
suspend before EC       Y               Y
suspend after EC        Y               Y
suspend_late            Y               Y
suspend_noirq           Y (actually N)  Y (actually N)
resume_noirq            Y (actually N)  Y (actually N)
resume_late             Y (actually N)  Y (actually N)
resume before EC        Y (actually N)  Y (actually N)
resume after EC         Y (actually N)  Y
after resume            Y (actually N)  Y
Where "actually N" means if there is no triggering source, the EC driver
is actually not able to notice the pending SCI_EVT occurred in the noirq
stage. So we can clearly see that this patch has improved the situation.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Todd E Brandt <todd.e.brandt@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-31 00:32:10 +02:00
Lv Zheng e923e8e79e ACPI / EC: Fix an issue that SCI_EVT cannot be detected after event is enabled
After enabling the EC event handling, Linux is still in the noirq stage, if
there is no triggering source (EC transaction, GPE STS status),
advance_transaction() will not be invoked and SCI_EVT cannot be detected.
This patch adds one more triggering source after enabling the EC event
handling to poll the pending SCI_EVT.

Known issues:
1. Still no SCI_EVT triggering source
   There could still be no SCI_EVT triggering source after handling the
   first SCI_EVT (polled by this patch if any). Because after handling the
   first SCI_EVT, Linux could still be in noirq stage and there could still
   be no further triggering source in this stage. Then the second SCI_EVT
   indicated during this stage still cannot be detected by the EC driver.
   With this improvement applied, it is then possible to move
   acpi_ec_enable_event() out of the noirq stage to fix this issue (if the
   first SCI_EVT is handled out of the noirq stage, the follow-up SCI_EVTs
   should be able to trigger IRQs).

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Todd E Brandt <todd.e.brandt@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-31 00:32:10 +02:00
Lv Zheng 750f628be6 ACPI / EC: Add EC_FLAGS_QUERY_ENABLED to reveal a hidden logic
There is a hidden logic in the EC driver:
1. During boot, EC_FLAGS_QUERY_PENDING is responsible for blocking event
   handling;
2. During suspend, EC_FLAGS_STARTED is responsible for blocking event
   handling.
This patch uses a new EC_FLAGS_QUERY_ENABLED flag to make this hidden
logic explicit and have code cleaned up. No functional change.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Todd E Brandt <todd.e.brandt@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-31 00:32:10 +02:00
Lv Zheng df45db6177 ACPI / EC: Add PM operations for suspend/resume noirq stage
It is reported that on some platforms, resume speed is not fast. The cause
is: in noirq stage, EC driver is working in polling mode, and each state
machine advancement requires a context switch.

The context switch is not necessary to the EC driver's polling mode. This
patch implements PM hooks to automatically switch the driver to/from the
busy polling mode to eliminate the overhead caused by the context switch.

This finally contributes to the tuning result: acpi_pm_finish() execution
time is improved from 192ms to 6ms.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reported-and-tested-by: Todd E Brandt <todd.e.brandt@linux.intel.com>
[ rjw: Subject ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-17 02:37:02 +02:00
Rafael J. Wysocki 4dc14b343d Merge branches 'acpi-ec' and 'acpi-button'
* acpi-ec:
  ACPI / EC: Work around method reentrancy limit in ACPICA for _Qxx

* acpi-button:
  ACPI / button: remove pointer to old lid_sysfs on unbind
2016-08-05 16:04:49 +02:00
Lv Zheng e1191bd4f6 ACPI / EC: Work around method reentrancy limit in ACPICA for _Qxx
A regression is caused by the following commit:

  Commit: 02b771b64b
  Subject: ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations

In this commit, using system workqueue causes that the maximum parallel
executions of _Qxx can exceed 255. This violates the method reentrancy
limit in ACPICA and generates the following error log:

  ACPI Error: Method reached maximum reentrancy limit (255) (20150818/dsmethod-341)

This patch creates a seperate workqueue and limits the number of parallel
_Qxx evaluations down to a configurable value (can be tuned against number
of online CPUs).

Since EC events are handled after driver probe, we can create the workqueue
in acpi_ec_init().

Fixes: 02b771b64b (ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=135691
Cc: 4.3+ <stable@vger.kernel.org> # 4.3+
Reported-and-tested-by: Helen Buus <ubuntu@hbuus.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-04 02:07:53 +02:00
Rafael J. Wysocki f6bc0a168e Merge branches 'acpi-ec', 'acpi-video', 'acpi-button' and 'acpi-thermal'
* acpi-ec:
  ACPI / EC: Remove wrong ECDT correction quirks
  ACPI / EC: Cleanup boot EC code using acpi_ec_alloc()

* acpi-video:
  ACPI / video: Dummy acpi_video_register should return error code
  ACPI / video: skip evaluating _DOD when it does not exist
  ACPI / video: Thinkpad X201 Tablet needs video_detect_force_video

* acpi-button:
  ACPI / button: Add quirks for initial lid state notification
  ACPI / button: Refactor functions to eliminate redundant code
  ACPI / button: Remove initial lid state notification

* acpi-thermal:
  ACPI / thermal: Remove create_workqueue()
2016-07-25 13:42:00 +02:00
Lv Zheng fa5b4a509d ACPI / EC: Fix code ordering issue in ec_remove_handlers()
There is an order issue in ec_remove_handlers() that acpi_ec_stop()
is called before removing the operation region handler. That is
incorrect, because the operation region handler removal triggers
_REG(DISCONNECT) which may result in new EC transactions to carry
out.

That existing issue has been triggered by the following commit:

    Commit: dcf15cbded
    Subject: ACPI / EC: Fix a boot EC regresion by restoring boot EC

which changed the driver to call ec_remove_handlers() after invoking
_REG(CONNECT), so the issue has become visible.

Fixes: dcf15cbded (ACPI / EC: Fix a boot EC regresion by restoring boot EC)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=102421
Reported-and-tested-by: Wolfram Sang <wsa@the-dreams.de>
Reported-by: Nicholas <nkudriavtsev@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-07-08 21:44:12 +02:00
Lv Zheng bc539567ab ACPI / EC: Remove wrong ECDT correction quirks
Our Windows probe result shows that EC._REG is evaluated after evaluating
all _INI/_STA control methods.

With boot EC always switched in acpi_ec_dsdt_probe(), we can see that as
long as there is no EC opregion accesses in the MLC (module level code, AML
code out of any control methods) and in _INI/_STA, there is no need to make
sure that ECDT must be correct.

Bugs of 9399/12461 were reported against an order issue that BAT0/1._STA
evaluations contain EC accesses while the ECDT setting is wrong.

>From the acpidump output posted on bug 9399, we can see that it is actually
a different issue. In this table, if EC._REG is not executed, EC accesses
will be done in a platform specific manner. As we've already ensured not to
execute EC._REG during the eary stage, we can remove the quirks for bug
9399.

From the acpidump output posted on bug 12461, we can see that it still
needs the quirk. In this table, EC._REG flags a named object whose default
value is One, thus BAT1._STA surely should invoke EC accesses whatever we
invoke EC._REG or not. We have to keep the quirk for it before we can root
cause the issue.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-07-04 15:30:06 +02:00
Lv Zheng fd6231e785 ACPI / EC: Cleanup boot EC code using acpi_ec_alloc()
Failure handling of the boot EC code is not tidy. This patch cleans
them up with acpi_ec_alloc().

This patch also changes acpi_ec_dsdt_probe(), always switches the
boot EC from the ECDT one to the DSDT one in this function.

Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-07-04 15:30:06 +02:00
Lv Zheng dcf15cbded ACPI / EC: Fix a boot EC regresion by restoring boot EC support for the DSDT EC
According to the Windows probing result, during the table loading, the EC
device described in the ECDT should be used. And the ECDT EC is also
effective during the period the namespace objects are initialized (we can
see a separate process executing _STA/_INI on Windows before executing
other device specific control methods, for example, EC._REG). During the
device enumration, the EC device described in the DSDT should be used. But
there are differences between Linux and Windows around the device probing
order. Thus in Linux, we should enable the DSDT EC as early as possible
before enumerating devices in order not to trigger issues related to the
device enumeration order differences.

This patch thus converts acpi_boot_ec_enable() into acpi_ec_dsdt_probe() to
fix the gap. This also fixes a user reported regression triggered after we
switched the "table loading"/"ECDT support" to be ACPI spec 2.0 compliant.

Fixes: 59f0aa9480 (ACPI 2.0 / ECDT: Remove early namespace reference from EC)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=119261
Reported-and-tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-06-07 02:29:53 +02:00
Lv Zheng 59f0aa9480 ACPI 2.0 / ECDT: Remove early namespace reference from EC
All operation region accesses are allowed by AML interpreter when AML is
executed, so actually BIOSen are responsible to avoid the operation region
accesses in AML before OSPM has prepared an operation region driver. This
is done via _REG control method. So AML code normally sets a global named
object REGC to 1 when _REG(3, 1) is evaluated.

Then what is ECDT? Quoting from ACPI spec 6.0, 5.2.15 Embedded Controller
Boot Resources Table (ECDT):
 "The presence of this table allows OSPM to provide Embedded Controller
  operation region space access before the namespace has been evaluated."
Spec also suggests a compatible mean to indicate the early EC access
availability:
 Device (EC)
 {
     Name (REGC, Ones)
     Method (_REG, 2)
     {
         If (LEqual (Arg0, 3))
         {
             Store (Arg1, REGC)
         }
     }
     Method (ECAV)
     {
         If (LEqual (REGC, Ones))
         {
             If (LGreaterEqual (_REV, 2))
             {
                 Return (One)
             }
             Else
             {
                 Return (Zero)
             }
         }
         Else
         {
             Return (REGC)
         }
     }
 }
In this way, it allows EC accesses to happen before EC._REG(3, 1) is
invoked.

But ECAV is not the only way practical BIOSen using to indicate the early
EC access availibility, the known variations include:
1. Setting REGC to One in \_SB._INI when _REV >= 2. Since \_SB._INI is the
   first control method evaluated by OSPM during the enumeration, this
   allows EC accesses to happen for the entire enumeration process before
   the namespace EC is enumerated.
2. Initialize REGC to One by default, this even allows EC accesses to
   happen during the table loading.

Linux is now broken around ECDT support during the long term bug fixing
work because it has merged many wrong ECDT bug fixes (see details below).
Linux currently uses namespace EC's settings instead of ECDT settings when
ECDT is detected. This apparently will result in namespace walk and
_CRS/_GPE/_REG evaluations. Such stuffs could only happen after namespace
is ready, while ECDT is purposely to be used before namespace is ready.

The wrong bug fixing story is:
1. Link 1:
   At Linux ACPI early stages, "no _Lxx/_Exx/_Qxx evaluation can happen
   before the namespace is ready" are not ensured by ACPICA core and Linux.
   This is currently ensured by deferred enabling of GPE and defered
   registering of EC query methods (acpi_ec_register_query_methods).
2. Link 2:
   Reporters reported buggy ECDTs, expecting quirks for the platform.
   Originally, the quirk is simple, only doing things with ECDT.
   Bug 9399 and 12461 are platforms (Asus L4R, Asus M6R, MSI MS-171F)
   reported to have wrong ECDT IO port addresses, the port addresses are
   reversed.
   Bug 11880 is a platform (Asus X50GL) reported to have 0 valued port
   addresses, we can see that all EC accesses are protected by ECAV on
   this platform, so actually no early EC accesses is required by this
   platform.
3. Link 3:
   But when the bug fixing developer was requested to provide a handy and
   non-quirk bug fix, he tried to use correct EC settings from namespace
   and broke the spec purpose. We can even see that the developer was
   suffered from many regrssions. One interesting one is 14086, where the
   actual root cause obviously should be: _REG is evaluated too early. But
   unfortunately, the bug is fixed in a totally wrong way.

So everything goes wrong from these commits:
   Commit: c6cb0e8784
   Subject: ACPI: EC: Don't trust ECDT tables from ASUS
   Commit: a5032bfdd9
   Subject: ACPI: EC: Always parse EC device

This patch reverts Linux behavior to simple ECDT quirk support in order to
stop early _CRS/_GPE/_REG evaluations.
For Bug 9399, 12461, since it is reported that the platforms require early
EC accesses, this patch restores the simple ECDT quirks for them.
For Bug 11880, since it is not reported that the platform requires early EC
accesses and its ACPI tables contain correct ECAV, we choose an ECDT
enumeration failure for this platform.

Link 1: https://bugzilla.kernel.org/show_bug.cgi?id=9916
        http://bugzilla.kernel.org/show_bug.cgi?id=10100
        https://lkml.org/lkml/2008/2/25/282
Link 2: https://bugzilla.kernel.org/show_bug.cgi?id=9399
        https://bugzilla.kernel.org/show_bug.cgi?id=12461
        https://bugzilla.kernel.org/show_bug.cgi?id=11880
Link 3: https://bugzilla.kernel.org/show_bug.cgi?id=11884
        https://bugzilla.kernel.org/show_bug.cgi?id=14081
        https://bugzilla.kernel.org/show_bug.cgi?id=14086
        https://bugzilla.kernel.org/show_bug.cgi?id=14446
Link 4: https://bugzilla.kernel.org/show_bug.cgi?id=112911
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-09 03:06:44 +02:00
Lv Zheng 0e1affe41b ACPI 2.0 / ECDT: Split EC_FLAGS_HANDLERS_INSTALLED
This patch splits EC_FLAGS_HANDLERS_INSTALLED so that address space handler
can be installed when it is not possible to install GPE handler during
early stage.
This patch also tunes address space handler installation, making it
happening earlier than GPE handler installation for the same purpose.

Since acpi_ec_start()/acpi_ec_stop() will be entered multiple times after
applying this change, it is also required to protect acpi_enable_gpe()/
acpi_disable_gpe() invocations.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=112911
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Tested-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-09 03:06:43 +02:00
Markus Elfring 4981c2b7ab ACPI-EC: Drop unnecessary check made before calling acpi_ec_delete_query()
The acpi_ec_delete_query() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
[ rjw: Subject ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-16 23:29:44 +01:00