Message-ID: <CAJZ5v0ijOF+nRZrjnub9uqa_Pu54etmudWUUNWmNgiogVAwxFQ@mail.gmail.com>
Date: Tue, 9 Dec 2025 23:18:10 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Armin Wolf <W_Armin@....de>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, 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

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.

Powered by blists - more mailing lists