Message-ID: <2ec8cf4c-62b2-4448-b4d6-563f519fd947@gmx.de>
Date: Wed, 10 Dec 2025 01:29:09 +0100
From: Armin Wolf <W_Armin@....de>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Linux ACPI <linux-acpi@...r.kernel.org>,
 Linux PM <linux-pm@...r.kernel.org>, Linux PCI <linux-pci@...r.kernel.org>,
 LKML <linux-kernel@...r.kernel.org>, Bjorn Helgaas <helgaas@...nel.org>
Subject: Re: [PATCH v1 0/2] PCI: ACPI: PM: Rework root bus wakeup notification
 setup and wakeup source registration

Am 09.12.25 um 23:18 schrieb Rafael J. Wysocki:

> On Tue, Dec 9, 2025 at 11:00 PM Armin Wolf <W_Armin@....de> wrote:
>> Am 09.12.25 um 14:56 schrieb Armin Wolf:
>>
>>> Am 09.12.25 um 12:31 schrieb Rafael J. Wysocki:
>>>
>>>> On Mon, Dec 8, 2025 at 9:01 PM Armin Wolf <W_Armin@....de> wrote:
>>>>> Am 08.12.25 um 13:09 schrieb Rafael J. Wysocki:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> 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!
>>>>> I tested both patches, and the sysfs layout changes as expected:
>>>>>
>>>>> $ 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,
>>>> Have you reported those?  What cpuidle driver is involved?
>>>>
>>>> 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.
>>> If i remember correctly the official 6.18 kernel was not affected by
>>> 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
>>>
>> Well, it turned out that the cpuidle driver was not involved in this, i just got confused
>> 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)
> It looks like there is a problem with turning a power resource off.
>
>> Sleeping itself works, it just takes a long time for the machine to actually suspend due to the timeout.
>> 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?
> It should be fine although you may as well check my pm-6.19-rc1,
> 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.

I tested all three tags atop of 6.18, and all can suspend just fine. I will thus wait for 6.19-rc1
before doing any further debugging.

Thanks,
Armin Wolf

Powered by blists - more mailing lists