user/sven/linux.git/drivers/acpi, branch v5.4.23

ACPI: PM: s2idle: Check fixed wakeup events in acpi_s2idle_wake()

2020-02-28T16:22:20Z

commit 63fb9623427fbb44e3782233b6e4714057b76ff2 upstream. Commit fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system") overlooked the fact that fixed events can wake up the system too and broke RTC wakeup from suspend-to-idle as a result. Fix this issue by checking the fixed events in acpi_s2idle_wake() in addition to checking wakeup GPEs and break out of the suspend-to-idle loop if the status bits of any enabled fixed events are set then. Fixes: fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system") Reported-and-tested-by: Chris Wilson Cc: 5.4+ # 5.4+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

ACPI: button: Add DMI quirk for Razer Blade Stealth 13 late 2019 lid switch

2020-02-24T07:36:43Z

[ Upstream commit 0528904926aab19bffb2068879aa44db166c6d5f ] Running evemu-record on the lid switch event shows that the lid reports the first "close" but then never reports an "open". This causes systemd to continuously re-suspend the laptop every 30s. Resetting the _LID to "open" fixes the issue. Signed-off-by: Jason Ekstrand Reviewed-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPICA: Disassembler: create buffer fields in ACPI_PARSE_LOAD_PASS1

2020-02-24T07:36:38Z

[ Upstream commit 5ddbd77181dfca61b16d2e2222382ea65637f1b9 ] ACPICA commit 29cc8dbc5463a93625bed87d7550a8bed8913bf4 create_buffer_field is a deferred op that is typically processed in load pass 2. However, disassembly of control method contents walk the parse tree with ACPI_PARSE_LOAD_PASS1 and AML_CREATE operators are processed in a later walk. This is a problem when there is a control method that has the same name as the AML_CREATE object. In this case, any use of the name segment will be detected as a method call rather than a reference to a buffer field. If this is detected as a method call, it can result in a mal-formed parse tree if the control methods have parameters. This change in processing AML_CREATE ops earlier solves this issue by inserting the named object in the ACPI namespace so that references to this name would be detected as a name string rather than a method call. Link: https://github.com/acpica/acpica/commit/29cc8dbc Reported-by: Elia Geretto Tested-by: Elia Geretto Signed-off-by: Bob Moore Signed-off-by: Erik Kaneda Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system

2020-02-19T18:52:57Z

commit fdde0ff8590b4c1c41b3227f5ac4265fccccb96b upstream. If the platform triggers a spurious SCI even though the status bit is not set for any GPE when the system is suspended to idle, it will be treated as a genuine wakeup, so avoid that by checking if any GPEs are active at all before returning 'true' from acpi_s2idle_wake(). Link: https://bugzilla.kernel.org/show_bug.cgi?id=206413 Fixes: 56b991849009 ("PM: sleep: Simplify suspend-to-idle control flow") Reported-by: Tsuchiya Yuto Cc: 5.4+ # 5.4+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPICA: Introduce acpi_any_gpe_status_set()

2020-02-19T18:52:57Z

commit ea128834dd76f9a72a35d011c651fa96658f06a7 upstream. Introduce a new helper function, acpi_any_gpe_status_set(), for checking the status bits of all enabled GPEs in one go. It is needed to distinguish spurious SCIs from genuine ones when deciding whether or not to wake up the system from suspend-to-idle. Cc: 5.4+ # 5.4+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI: PM: s2idle: Avoid possible race related to the EC GPE

2020-02-19T18:52:56Z

commit e3728b50cd9be7d4b1469447cdf1feb93e3b7adb upstream. It is theoretically possible for the ACPI EC GPE to be set after the s2idle_ops->wake() called from s2idle_loop() has returned and before the subsequent pm_wakeup_pending() check is carried out. If that happens, the resulting wakeup event will cause the system to resume even though it may be a spurious one. To avoid that race, first make the ->wake() callback in struct platform_s2idle_ops return a bool value indicating whether or not to let the system resume and rearrange s2idle_loop() to use that value instad of the direct pm_wakeup_pending() call if ->wake() is present. Next, rework acpi_s2idle_wake() to process EC events and check pm_wakeup_pending() before re-arming the SCI for system wakeup to prevent it from triggering prematurely and add comments to that function to explain the rationale for the new code flow. Fixes: 56b991849009 ("PM: sleep: Simplify suspend-to-idle control flow") Cc: 5.4+ # 5.4+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI: EC: Fix flushing of pending work

2020-02-19T18:52:56Z

commit f0ac20c3f6137910c8a927953e8a92f5b3716166 upstream. Commit 016b87ca5c8c ("ACPI: EC: Rework flushing of pending work") introduced a subtle bug into the flushing of pending EC work while suspended to idle, which may cause the EC driver to fail to re-enable the EC GPE after handling a non-wakeup event (like a battery status change event, for example). The problem is that the work item flushed by flush_scheduled_work() in __acpi_ec_flush_work() may disable the EC GPE and schedule another work item expected to re-enable it, but that new work item is not flushed, so __acpi_ec_flush_work() returns with the EC GPE disabled and the CPU running it goes into an idle state subsequently. If all of the other CPUs are in idle states at that point, the EC GPE won't be re-enabled until at least one CPU is woken up by another interrupt source, so system wakeup events that would normally come from the EC then don't work. This is reproducible on a Dell XPS13 9360 in my office which sometimes stops reacting to power button and lid events (triggered by the EC on that machine) after switching from AC power to battery power or vice versa while suspended to idle (each of those switches causes the EC GPE to trigger for several times in a row, but they are not system wakeup events). To avoid this problem, it is necessary to drain the workqueue entirely in __acpi_ec_flush_work(), but that cannot be done with respect to system_wq, because work items may be added to it from other places while __acpi_ec_flush_work() is running. For this reason, make the EC driver use a dedicated workqueue for EC events processing (let that workqueue be ordered so that EC events are processed sequentially) and use drain_workqueue() on it in __acpi_ec_flush_work(). Fixes: 016b87ca5c8c ("ACPI: EC: Rework flushing of pending work") Cc: 5.4+ # 5.4+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI / battery: Deal better with neither design nor full capacity not being reported

2020-02-11T12:35:20Z

commit ff3154d1d89a2343fd5f82e65bc0cf1d4e6659b3 upstream. Commit b41901a2cf06 ("ACPI / battery: Do not export energy_full[_design] on devices without full_charge_capacity") added support for some (broken) devices which always report 0 for both design_capacity and full_charge_capacity. Since the device that commit was written as a fix for is not reporting any form of "full" capacity we cannot calculate the value for the POWER_SUPPLY_PROP_CAPACITY, this is worked around by using an alternative array of available properties which does not contain this property. This is necessary because userspace (upower) treats us returning -ENODEV as 0 and then typically will trigger an emergency shutdown because of that. Userspace does not do this if the capacity sysfs attribute is not present at all. There are two potential problems with that commit: 1) It assumes that both full_charge- and design-capacity are broken at the same time and only checks if full_charge- is broken. 2) It assumes that this only ever happens for devices which report energy units rather then charge units. This commit fixes both issues by only using the alternative array of available properties if both full_charge- and design-capacity are broken and by also adding an alternative array of available properties for devices using mA units. Fixes: b41901a2cf06 ("ACPI / battery: Do not export energy_full[_design] on devices without full_charge_capacity") Cc: 4.19+ # 4.19+ Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI / battery: Use design-cap for capacity calculations if full-cap is not available

2020-02-11T12:35:19Z

commit 5b74d1d16e2f5753fcbdecd6771b2d8370dda414 upstream. The ThunderSoft TS178 tablet's _BIX implementation reports design_capacity but not full_charge_capacity. Before this commit this would cause us to return -ENODEV for the capacity attribute, which userspace does not like. Specifically upower does this: if (sysfs_file_exists (native_path, "capacity")) { percentage = sysfs_get_double (native_path, "capacity"); Where the sysfs_get_double() helper returns 0 when we return -ENODEV, so the battery always reads 0% if we return -ENODEV. This commit fixes this by using the design-capacity instead of the full-charge-capacity when the full-charge-capacity is not available. Fixes: b41901a2cf06 ("ACPI / battery: Do not export energy_full[_design] on devices without full_charge_capacity") Cc: 4.19+ # 4.19+ Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI / battery: Deal with design or full capacity being reported as -1

2020-02-11T12:35:19Z

commit cc99f0ad52467028cb1251160f23ad4bb65baf20 upstream. Commit b41901a2cf06 ("ACPI / battery: Do not export energy_full[_design] on devices without full_charge_capacity") added support for some (broken) devices which always report 0 for both design- and full_charge-capacity. This assumes that if the capacity is not being reported it is 0. The ThunderSoft TS178 tablet's _BIX implementation falsifies this assumption. It reports ACPI_BATTERY_VALUE_UNKNOWN (-1) as full_charge_capacity, which we treat as a valid value which causes several problems. This commit fixes this by adding a new ACPI_BATTERY_CAPACITY_VALID() helper which checks that the value is not 0 and not -1; and using this whenever we need to test if either design_capacity or full_charge_capacity is valid. Fixes: b41901a2cf06 ("ACPI / battery: Do not export energy_full[_design] on devices without full_charge_capacity") Cc: 4.19+ # 4.19+ Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman