linux-toradex.git/drivers/acpi, branch v5.17 Linux kernel for Apalis and Colibri modules Revert "ACPI: scan: Do not add device IDs from _CID if _HID is not valid" 2022-03-16T10:23:05+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2022-03-16T10:23:05+00:00 462ccc35a750f335c8456cde9120b8b593fff60f Revert commit e38f9ff63e6d ("ACPI: scan: Do not add device IDs from _CID if _HID is not valid"), because it has introduced regressions on multiple systems, even though it only has effect on clearly invalid firmware. Reported-by: Pierre-Louis Bossart <notifications@github.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
Revert commit e38f9ff63e6d ("ACPI: scan: Do not add device IDs from _CID
if _HID is not valid"), because it has introduced regressions on
multiple systems, even though it only has effect on clearly invalid
firmware.

Reported-by: Pierre-Louis Bossart <notifications@github.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge branch 'acpi-processor' 2022-02-18T18:36:36+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2022-02-18T18:36:36+00:00 8292656464e5f066d46cb73da957930613a2c597 Merge fix for a recent boot lockup regression on 32-bit ThinkPad T40. * acpi-processor: ACPI: processor: idle: fix lockup regression on 32-bit ThinkPad T40 
Merge fix for a recent boot lockup regression on 32-bit ThinkPad T40.

* acpi-processor:
  ACPI: processor: idle: fix lockup regression on 32-bit ThinkPad T40
ACPI: processor: idle: fix lockup regression on 32-bit ThinkPad T40 2022-02-16T17:17:16+00:00 Woody Suwalski wsuwalski@gmail.com 2022-02-09T21:05:09+00:00 bfe55a1f7fd6bfede16078bf04c6250fbca11588 Add and ACPI idle power level limit for 32-bit ThinkPad T40. There is a regression on T40 introduced by commit d6b88ce2, starting with kernel 5.16: commit d6b88ce2eb9d2698eb24451eb92c0a1649b17bb1 Author: Richard Gong <richard.gong@amd.com> Date:   Wed Sep 22 08:31:16 2021 -0500 ACPI: processor idle: Allow playing dead in C3 state The above patch is trying to enter C3 state during init, what is causing a T40 system freeze. I have not found a similar issue on any other of my 32-bit machines. The fix is to add another exception to the processor_power_dmi_table[] list. As a result the dmesg shows as expected: [2.155398] ACPI: IBM ThinkPad T40 detected - limiting to C2 max_cstate. Override with "processor.max_cstate=9" [2.155404] ACPI: processor limited to max C-state 2 The fix is trivial and affects only vintage T40 systems. Fixes: d6b88ce2eb9d ("CPI: processor idle: Allow playing dead in C3 state") Signed-off-by: Woody Suwalski <wsuwalski@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Cc: 5.16+ <stable@vger.kernel.org> # 5.16+ [ rjw: New subject ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
Add and ACPI idle power level limit for 32-bit ThinkPad T40.

There is a regression on T40 introduced by commit d6b88ce2, starting
with kernel 5.16:

commit d6b88ce2eb9d2698eb24451eb92c0a1649b17bb1
Author: Richard Gong <richard.gong@amd.com>
Date:   Wed Sep 22 08:31:16 2021 -0500

  ACPI: processor idle: Allow playing dead in C3 state

The above patch is trying to enter C3 state during init, what is causing
a T40 system freeze. I have not found a similar issue on any other of my
32-bit machines.

The fix is to add another exception to the processor_power_dmi_table[] list.
As a result the dmesg shows as expected:

[2.155398] ACPI: IBM ThinkPad T40 detected - limiting to C2 max_cstate. Override with "processor.max_cstate=9"
[2.155404] ACPI: processor limited to max C-state 2

The fix is trivial and affects only vintage T40 systems.

Fixes: d6b88ce2eb9d ("CPI: processor idle: Allow playing dead in C3 state")
Signed-off-by: Woody Suwalski <wsuwalski@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Cc: 5.16+ <stable@vger.kernel.org> # 5.16+
[ rjw: New subject ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI: tables: Quiet ACPI table not found warning 2022-02-15T19:03:16+00:00 Dan Williams dan.j.williams@intel.com 2022-02-15T18:54:23+00:00 f98da1d66298882b1d2061051ea14ddc15c58884 Paul reports that the ACPI core complains on every boot about a missing CEDT table. Unlike the standard NUMA tables (SRAT, MADT, and SLIT) that are critical to NUMA init, CEDT is only expected on CXL platforms. Given the notice is not actionable lower its severity to debug. Link: https://lore.kernel.org/r/55f5c077-061c-7e53-b02d-53dde1dd654f@molgen.mpg.de Fixes: fd49f99c1809 ("ACPI: NUMA: Add a node and memblk for each CFMWS not in SRAT") Reported-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
Paul reports that the ACPI core complains on every boot about a missing
CEDT table. Unlike the standard NUMA tables (SRAT, MADT, and SLIT) that
are critical to NUMA init, CEDT is only expected on CXL platforms. Given
the notice is not actionable lower its severity to debug.

Link: https://lore.kernel.org/r/55f5c077-061c-7e53-b02d-53dde1dd654f@molgen.mpg.de
Fixes: fd49f99c1809 ("ACPI: NUMA: Add a node and memblk for each CFMWS not in SRAT")
Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux 2022-02-11T19:55:26+00:00 Linus Torvalds torvalds@linux-foundation.org 2022-02-11T19:55:26+00:00 e47ca403262680db81dbd8bbfd40e7f522c7f147 Pull arm64 fixes from Catalin Marinas: - Enable Cortex-A510 erratum 2051678 by default as we do with other errata. - arm64 IORT: Check the node revision for PMCG resources to cope with old firmware based on a broken revision of the spec that had no way to describe the second register page (when an implementation is using the recommended RELOC_CTRS feature). * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: ACPI/IORT: Check node revision for PMCG resources arm64: Enable Cortex-A510 erratum 2051678 by default 
Pull arm64 fixes from Catalin Marinas:

 - Enable Cortex-A510 erratum 2051678 by default as we do with other
   errata.

 - arm64 IORT: Check the node revision for PMCG resources to cope with
   old firmware based on a broken revision of the spec that had no way
   to describe the second register page (when an implementation is using
   the recommended RELOC_CTRS feature).

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  ACPI/IORT: Check node revision for PMCG resources
  arm64: Enable Cortex-A510 erratum 2051678 by default
ACPI/IORT: Check node revision for PMCG resources 2022-02-09T18:16:22+00:00 Robin Murphy robin.murphy@arm.com 2022-02-03T19:31:24+00:00 da5fb9e1ad3fbf632dce735f1bdad257ca528499 The original version of the IORT PMCG definition had an oversight wherein there was no way to describe the second register page for an implementation using the recommended RELOC_CTRS feature. Although the spec was fixed, and the final patches merged to ACPICA and Linux written against the new version, it seems that some old firmware based on the original revision has survived and turned up in the wild. Add a check for the original PMCG definition, and avoid filling in the second memory resource with nonsense if so. Otherwise it is likely that something horrible will happen when the PMCG driver attempts to probe. Reported-by: Michael Petlan <mpetlan@redhat.com> Fixes: 24e516049360 ("ACPI/IORT: Add support for PMCG") Cc: <stable@vger.kernel.org> # 5.2.x Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Link: https://lore.kernel.org/r/75628ae41c257fb73588f7bf1c4459160e04be2b.1643916258.git.robin.murphy@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> 
The original version of the IORT PMCG definition had an oversight
wherein there was no way to describe the second register page for an
implementation using the recommended RELOC_CTRS feature. Although the
spec was fixed, and the final patches merged to ACPICA and Linux written
against the new version, it seems that some old firmware based on the
original revision has survived and turned up in the wild.

Add a check for the original PMCG definition, and avoid filling in the
second memory resource with nonsense if so. Otherwise it is likely that
something horrible will happen when the PMCG driver attempts to probe.

Reported-by: Michael Petlan <mpetlan@redhat.com>
Fixes: 24e516049360 ("ACPI/IORT: Add support for PMCG")
Cc: <stable@vger.kernel.org> # 5.2.x
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Link: https://lore.kernel.org/r/75628ae41c257fb73588f7bf1c4459160e04be2b.1643916258.git.robin.murphy@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
PM: s2idle: ACPI: Fix wakeup interrupts handling 2022-02-07T20:02:31+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2022-02-04T17:35:22+00:00 cb1f65c1e1424a4b5e4a86da8aa3b8fd8459c8ec After commit e3728b50cd9b ("ACPI: PM: s2idle: Avoid possible race related to the EC GPE") wakeup interrupts occurring immediately after the one discarded by acpi_s2idle_wake() may be missed. Moreover, if the SCI triggers again immediately after the rearming in acpi_s2idle_wake(), that wakeup may be missed too. The problem is that pm_system_irq_wakeup() only calls pm_system_wakeup() when pm_wakeup_irq is 0, but that's not the case any more after the interrupt causing acpi_s2idle_wake() to run until pm_wakeup_irq is cleared by the pm_wakeup_clear() call in s2idle_loop(). However, there may be wakeup interrupts occurring in that time frame and if that happens, they will be missed. To address that issue first move the clearing of pm_wakeup_irq to the point at which it is known that the interrupt causing acpi_s2idle_wake() to tun will be discarded, before rearming the SCI for wakeup. Moreover, because that only reduces the size of the time window in which the issue may manifest itself, allow pm_system_irq_wakeup() to register two second wakeup interrupts in a row and, when discarding the first one, replace it with the second one. [Of course, this assumes that only one wakeup interrupt can be discarded in one go, but currently that is the case and I am not aware of any plans to change that.] Fixes: e3728b50cd9b ("ACPI: PM: s2idle: Avoid possible race related to the EC GPE") Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
After commit e3728b50cd9b ("ACPI: PM: s2idle: Avoid possible race
related to the EC GPE") wakeup interrupts occurring immediately after
the one discarded by acpi_s2idle_wake() may be missed.  Moreover, if
the SCI triggers again immediately after the rearming in
acpi_s2idle_wake(), that wakeup may be missed too.

The problem is that pm_system_irq_wakeup() only calls pm_system_wakeup()
when pm_wakeup_irq is 0, but that's not the case any more after the
interrupt causing acpi_s2idle_wake() to run until pm_wakeup_irq is
cleared by the pm_wakeup_clear() call in s2idle_loop().  However,
there may be wakeup interrupts occurring in that time frame and if
that happens, they will be missed.

To address that issue first move the clearing of pm_wakeup_irq to
the point at which it is known that the interrupt causing
acpi_s2idle_wake() to tun will be discarded, before rearming the SCI
for wakeup.  Moreover, because that only reduces the size of the
time window in which the issue may manifest itself, allow
pm_system_irq_wakeup() to register two second wakeup interrupts in
a row and, when discarding the first one, replace it with the second
one.  [Of course, this assumes that only one wakeup interrupt can be
discarded in one go, but currently that is the case and I am not
aware of any plans to change that.]

Fixes: e3728b50cd9b ("ACPI: PM: s2idle: Avoid possible race related to the EC GPE")
Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI: PM: s2idle: Cancel wakeup before dispatching EC GPE 2022-02-07T20:02:31+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2022-02-04T17:31:02+00:00 dc0075ba7f387fe4c48a8c674b11ab6f374a6acc Commit 4a9af6cac050 ("ACPI: EC: Rework flushing of EC work while suspended to idle") made acpi_ec_dispatch_gpe() check pm_wakeup_pending(), but that is before canceling the SCI wakeup, so pm_wakeup_pending() is always true. This causes the loop in acpi_ec_dispatch_gpe() to always terminate after one iteration which may not be correct. Address this issue by canceling the SCI wakeup earlier, from acpi_ec_dispatch_gpe() itself. Fixes: 4a9af6cac050 ("ACPI: EC: Rework flushing of EC work while suspended to idle") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
Commit 4a9af6cac050 ("ACPI: EC: Rework flushing of EC work while
suspended to idle") made acpi_ec_dispatch_gpe() check
pm_wakeup_pending(), but that is before canceling the SCI wakeup,
so pm_wakeup_pending() is always true.  This causes the loop in
acpi_ec_dispatch_gpe() to always terminate after one iteration which
may not be correct.

Address this issue by canceling the SCI wakeup earlier, from
acpi_ec_dispatch_gpe() itself.

Fixes: 4a9af6cac050 ("ACPI: EC: Rework flushing of EC work while suspended to idle")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI: PM: Revert "Only mark EC GPE for wakeup on Intel systems" 2022-02-07T20:02:31+00:00 Mario Limonciello mario.limonciello@amd.com 2022-01-28T20:35:03+00:00 d6ebb17ccc7b37872a32bc25b4a21f1e5af8c7e3 Testing on various upcoming OEM systems shows commit 7b167c4cb48e ("ACPI: PM: Only mark EC GPE for wakeup on Intel systems") was short sighted and the symptoms were indicative of other problems. Some OEMs do have the dedicated GPIOs for the power button but also rely upon an interrupt to the EC SCI to let the lid work. The original commit showed spurious activity on Lenovo systems: * On both Lenovo T14 and P14s the keyboard wakeup doesn't work, and sometimes the power button event doesn't work. This was confirmed on my end at that time. However further development in the kernel showed that the issue was actually the IRQ for the GPIO controller was also shared with the EC SCI. This was actually fixed by commit 2d54067fcd23 ("pinctrl: amd: Fix wakeups when IRQ is shared with SCI"). The original commit also showed problems with AC adapter: * On HP 635 G7 detaching or attaching AC during suspend will cause the system not to wakeup * On Asus vivobook to prevent detaching AC causing resume problems * On Lenovo 14ARE05 to prevent detaching AC causing resume problems * On HP ENVY x360 to prevent detaching AC causing resume problems Detaching AC adapter causing problems appears to have been a problem because the EC SCI went off to notify the OS of the power adapter change but the SCI was ignored and there was no other way to wake up this system since GPIO controller wasn't properly enabled. The wakeups were fixed by enabling the GPIO controller in commit acd47b9f28e5 ("pinctrl: amd: Handle wake-up interrupt"). I've confirmed on a variety of OEM notebooks with the following test 1) echo 1 | sudo tee /sys/power/pm_debug_messages 2) sudo systemctl suspend 3) unplug AC adapter, make sure system is still asleep 4) wake system from lid (which is provided by ACPI SCI on some of them) 5) dmesg a) see the EC GPE dispatched, timekeeping for X seconds (matching ~time until AC adapter plug out) b) see timekeeping for Y seconds until woke (matching ~time from AC adapter until lid event) 6) Look at /sys/kernel/debug/amd_pmc/s0ix_stats "Time (in us) in S0i3" = X + Y - firmware processing time Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
Testing on various upcoming OEM systems shows commit 7b167c4cb48e ("ACPI:
PM: Only mark EC GPE for wakeup on Intel systems") was short
sighted and the symptoms were indicative of other problems. Some OEMs
do have the dedicated GPIOs for the power button but also rely upon
an interrupt to the EC SCI to let the lid work.

The original commit showed spurious activity on Lenovo systems:
     * On both Lenovo T14 and P14s the keyboard wakeup doesn't work, and
       sometimes the power button event doesn't work.

This was confirmed on my end at that time.

However further development in the kernel showed that the issue was
actually the IRQ for the GPIO controller was also shared with the EC SCI.
This was actually fixed by commit 2d54067fcd23 ("pinctrl: amd: Fix
wakeups when IRQ is shared with SCI").

The original commit also showed problems with AC adapter:
     * On HP 635 G7 detaching or attaching AC during suspend will cause
       the system not to wakeup
     * On Asus vivobook to prevent detaching AC causing resume problems
     * On Lenovo 14ARE05 to prevent detaching AC causing resume problems
     * On HP ENVY x360  to prevent detaching AC causing resume problems

Detaching AC adapter causing problems appears to have been a problem
because the EC SCI went off to notify the OS of the power adapter change
but the SCI was ignored and there was no other way to wake up this system
since GPIO controller wasn't properly enabled.  The wakeups were fixed by
enabling the GPIO controller in commit acd47b9f28e5 ("pinctrl: amd: Handle
wake-up interrupt").

I've confirmed on a variety of OEM notebooks with the following test

 1) echo 1 | sudo tee /sys/power/pm_debug_messages
 2) sudo systemctl suspend
 3) unplug AC adapter, make sure system is still asleep
 4) wake system from lid (which is provided by ACPI SCI on some of them)
 5) dmesg
    a) see the EC GPE dispatched, timekeeping for X seconds (matching ~time
       until AC adapter plug out)
    b) see timekeeping for Y seconds until woke (matching ~time from AC
       adapter until lid event)
 6) Look at /sys/kernel/debug/amd_pmc/s0ix_stats
    "Time (in us) in S0i3" = X + Y - firmware processing time

Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI: require CRC32 to build 2022-01-31T19:16:28+00:00 Randy Dunlap rdunlap@infradead.org 2022-01-30T22:38:18+00:00 04662bac0067e2fd7f243d6abaa4d779bce14114 ACPI core now requires crc32() but the kernel build can fail when CRC32 is not set/enabled, so select it in the ACPI Kconfig entry. Fixes this build error: ia64-linux-ld: drivers/acpi/scan.o: in function `acpi_store_pld_crc': include/acpi/platform/aclinuxex.h:62: undefined reference to `crc32_le' Fixes: 882c982dada4 ("acpi: Store CRC-32 hash of the _PLD in struct acpi_device") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
ACPI core now requires crc32() but the kernel build can fail when
CRC32 is not set/enabled, so select it in the ACPI Kconfig entry.

Fixes this build error:

ia64-linux-ld: drivers/acpi/scan.o: in function `acpi_store_pld_crc':
include/acpi/platform/aclinuxex.h:62: undefined reference to `crc32_le'

Fixes: 882c982dada4 ("acpi: Store CRC-32 hash of the _PLD in struct acpi_device")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>