Re: [PATCH v1 0/2] PCI: ACPI: PM: Rework root bus wakeup notification setup and wakeup source registration
From: Armin Wolf
Date: Sat Dec 20 2025 - 07:56:35 EST
Am 10.12.25 um 02:56 schrieb Rafael J. Wysocki:
On Wed, Dec 10, 2025 at 1:29 AM Armin Wolf <W_Armin@xxxxxx> wrote:
Am 09.12.25 um 23:18 schrieb Rafael J. Wysocki:Sounds reasonable to me.
On Tue, Dec 9, 2025 at 11:00 PM Armin Wolf <W_Armin@xxxxxx> wrote:I tested all three tags atop of 6.18, and all can suspend just fine. I will thus wait for 6.19-rc1
Am 09.12.25 um 14:56 schrieb Armin Wolf:It looks like there is a problem with turning a power resource off.
Am 09.12.25 um 12:31 schrieb Rafael J. Wysocki:Well, it turned out that the cpuidle driver was not involved in this, i just got confused
On Mon, Dec 8, 2025 at 9:01 PM Armin Wolf <W_Armin@xxxxxx> wrote:If i remember correctly the official 6.18 kernel was not affected by
Am 08.12.25 um 13:09 schrieb Rafael J. Wysocki:Have you reported those? What cpuidle driver is involved?
Hi All,I tested both patches, and the sysfs layout changes as expected:
Patch [1/2] updates the registration of PCI root bus wakeup
notification setup
in order to simplify code in pci_acpi_wake_bus() and to prepare for
the other
change. This is not expected to affect functionality.
Patch [2/2] modifies the ACPI PM notifier registration to add
wakeup sources
under devices that are going to be affected by wakeup handling
instead of
registering them under ACPI companions of those devices (rationale
explained
in the patch changelog). This will change the sysfs layout (wakeup
source
devices associated with PCI wakeup are now going to appear under
PCI devices
and the host bridge device), but it is not expected to affect user
space
adversely.
Thanks!
$ readlink /sys/class/wakeup/wakeup*/device
../../../device:00
../../../device:1a
../../../device:1f
../../../device:20
../../../0000:00:08.1
../../../device:36
../../../device:31
../../../device:32
../../../device:3c
../../../0000:01:00.0
../../../device:3d
../../../PNP0C02:00
../../../0000:02:00.0
../../../device:3e
../../../device:3f
../../../device:46
../../../0000:04:00.0
../../../device:47
../../../0000:05:00.0
../../../device:57
../../../0000:05:08.0
../../../device:59
../../../device:01
../../../0000:05:09.0
../../../device:5b
../../../0000:05:0a.0
../../../device:5d
../../../0000:05:0b.0
../../../device:5f
../../../0000:05:0c.0
../../../device:74
../../../0000:05:0d.0
../../../device:5a
../../../device:3a
../../../device:5c
../../../device:60
../../../device:75
../../../LNXVIDEO:00
../../../device:22
../../../PNP0C02:02
../../../device:25
../../../device:2b
../../../device:24
../../../device:37
../../../0000:00:01.1
../../../PNP0A08:00
../../../LNXPWRBN:00
../../../AMDI0010:00
../../../AMDI0030:00
../../../00:02
../../../alarmtimer.0.auto
../../../PNP0C0C:00
../../../0000:0b:00.0
../../../AMDIF031:00
../../../PNP0C14:00
../../../device:0a
../../../PNP0C14:01
../../../PNP0C14:02
../../../PNP0C14:03
../../../0000:0e:00.3
../../../0000:0e:00.4
../../../0000:0f:00.0
../../../5-2
../../../1-5.3
../../hidpp_battery_0
../../../device:44
../../../0000:00:02.1
../../../device:76
../../../device:0b
turns into:
$ readlink /sys/class/wakeup/wakeup*/device
../../../0000:00:00.0
../../../0000:00:04.0
../../../0000:00:08.0
../../../0000:00:08.1
../../../0000:00:08.1
../../../0000:00:08.3
../../../0000:00:14.0
../../../0000:00:14.3
../../../0000:01:00.0
../../../0000:01:00.0
../../../0000:02:00.0
../../../0000:00:00.2
../../../0000:02:00.0
../../../0000:03:00.0
../../../0000:03:00.1
../../../0000:04:00.0
../../../0000:04:00.0
../../../0000:05:00.0
../../../0000:05:00.0
../../../0000:05:08.0
../../../0000:05:08.0
../../../0000:05:09.0
../../../0000:00:01.0
../../../0000:05:09.0
../../../0000:05:0a.0
../../../0000:05:0a.0
../../../0000:05:0b.0
../../../0000:05:0b.0
../../../0000:05:0c.0
../../../0000:05:0c.0
../../../0000:05:0d.0
../../../0000:05:0d.0
../../../0000:08:00.0
../../../0000:00:01.1
../../../0000:09:00.0
../../../0000:0b:00.0
../../../0000:0c:00.0
../../../0000:0e:00.0
../../../0000:0e:00.1
../../../0000:0e:00.2
../../../0000:0e:00.3
../../../0000:0e:00.4
../../../0000:0e:00.6
../../../0000:0f:00.0
../../../0000:00:01.1
../../../pci0000:00
../../../LNXPWRBN:00
../../../AMDI0010:00
../../../AMDI0030:00
../../../00:02
../../../alarmtimer.0.auto
../../../PNP0C0C:00
../../../0000:0b:00.0
../../../AMDIF031:00
../../../PNP0C14:00
../../../0000:00:02.0
../../../PNP0C14:01
../../../PNP0C14:02
../../../PNP0C14:03
../../../0000:0e:00.3
../../../0000:0e:00.4
../../../0000:0f:00.0
../../../5-2
../../../1-5.3
../../hidpp_battery_0
../../../0000:00:02.1
../../../0000:00:02.1
../../../0000:00:02.2
../../../0000:00:03.0
The remaining ACPI devices are likely caused by device drivers based
upon struct acpi_driver.
I was unable to test the wakeup itself since suspend is currently
broken due to issues with
cpuidle,
If you happen to be using the ACPI idle driver, there is a regression
between 6.18-rc7 and final 6.18 due to a missing revert, but final
6.18 should be as expected.
this, i used the the bleeding-edge
branch when building the test kernel.
I will do some further debugging once i am back home.
Thanks,
Armin Wolf
by a separate stacktrace caused by the hid-roccat driver (i already reported that).
This seems to be the real issue:
[ 514.910759] ACPI Error: Aborting method \M402 due to previous error (AE_AML_LOOP_TIMEOUT) (20250807/psparse-529)
[ 514.910810] ACPI Error: Aborting method \_SB.PCI0.GPP0.M241 due to previous error (AE_AML_LOOP_TIMEOUT) (20250807/psparse-529)
[ 514.910890] ACPI Error: Aborting method \_SB.PCI0.GPP0.M237._OFF due to previous error (AE_AML_LOOP_TIMEOUT) (20250807/psparse-529)
Sleeping itself works, it just takes a long time for the machine to actually suspend due to the timeout.It should be fine although you may as well check my pm-6.19-rc1,
I attached the acpidump of the affected machine in case you are interested.
Since 6.18 is not affected by this i will wait till 6.19-rc1 is released before i start debugging this issue.
Do you think that this approach is OK?
acpi-6.19-rc1 and thermal-6.19-rc1 tags on top of 6.18. If the
problem is in one of them, it should be possible to find it quicker
than by dealing with the entire 6.19-rc1.
before doing any further debugging.
Well, after two failed bisects caused by the fact that the resulting kernel unexpectedly changed his name,
i will try again later. Sorry for taking so long, but i am quite inexperienced when it comes to performing
such a large bisect.
Thanks,
Armin Wolf