Message-ID: <CAJZ5v0h5jWx4vvxTXus80290zu7OjQY_FobLFHqYF205WadDOQ@mail.gmail.com>
Date: Wed, 10 Dec 2025 02:56:27 +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 Wed, Dec 10, 2025 at 1:29 AM Armin Wolf <W_Armin@....de> wrote:
>
> 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.

Sounds reasonable to me.

Powered by blists - more mailing lists