drivers/pci/pci-driver.c | 109 +++++++++++++++++++++++++-------------- 1 file changed, 69 insertions(+), 40 deletions(-)
A few cycles ago I sent out a kernel series for using the S4 paths when the system goes to S5. Some parts of it got merged, and Rafael suggested to split the other parts into smaller pieces across multiple kernel cycles to make bisecting easier. This fell into my backlog behind other things, so I wanted to try again this cycle for the PCI pieces. I have been carrying it, rebasing it and personally using it for a while now though. This series attempts to unify the PCI suspend and hibernate paths and to fix some things that I observed to be wrong with how I expect hibernate to work. Based off v7.1-rc1 v2: - Include Lukas' patch from pci/pm directly in series so Sashiko can better review. - Include linux-pm in CC. Lukas Wunner (1): PCI: Stop setting cached power state to "unknown" on unbind Mario Limonciello (AMD) (5): PCI/PM: Disable device wakeups when halting or powering off system PCI/PM: Split out code from pci_pm_suspend_noirq() into helper PCI/PM: Run bridge power up actions as part of restore phase PCI/PM: Use pci_power_manageable() in pci_pm_poweroff_noirq() PCI: Put PCIe bridges with downstream devices into D3 at hibernate drivers/pci/pci-driver.c | 109 +++++++++++++++++++++++++-------------- 1 file changed, 69 insertions(+), 40 deletions(-) -- 2.53.0
On Mon, Apr 27, 2026 at 03:50:18PM -0500, Mario Limonciello (AMD) wrote: > A few cycles ago I sent out a kernel series for using the S4 paths when > the system goes to S5. Some parts of it got merged, and Rafael suggested > to split the other parts into smaller pieces across multiple kernel cycles > to make bisecting easier. Thanks for posting this again. Sashiko had a few questions: https://sashiko.dev/#/patchset/20260427205024.254677-1-superm1%40kernel.org I didn't look at them in detail, although I did think the ACPI r6.5 sec 16.1.5 reference was a little bit obscure. The diagram in sec 16.1 certainly implies that wakeups only occur in S1-S4 and not in S5. Sec 16.1.5 does mention "Remote Start", which is completely undefined by the spec but searching does find sec 7.4.2.6, which clearly says the system requires a complete boot when awakened. Possibly a little misleading to refer to Remote Start as "awakening" when it's apparently not a "wakeup". That section also says "OSPM does not disable wake events before setting the SLP_EN bit when entering the S5 system state."
On 4/28/26 16:51, Bjorn Helgaas wrote: > On Mon, Apr 27, 2026 at 03:50:18PM -0500, Mario Limonciello (AMD) wrote: >> A few cycles ago I sent out a kernel series for using the S4 paths when >> the system goes to S5. Some parts of it got merged, and Rafael suggested >> to split the other parts into smaller pieces across multiple kernel cycles >> to make bisecting easier. > > Thanks for posting this again. Sashiko had a few questions: > https://sashiko.dev/#/patchset/20260427205024.254677-1-superm1%40kernel.org > > I didn't look at them in detail, although I did think the ACPI r6.5 > sec 16.1.5 reference was a little bit obscure. The diagram in sec > 16.1 certainly implies that wakeups only occur in S1-S4 and not in S5. > > Sec 16.1.5 does mention "Remote Start", which is completely undefined > by the spec but searching does find sec 7.4.2.6, which clearly says > the system requires a complete boot when awakened. Possibly a little > misleading to refer to Remote Start as "awakening" when it's > apparently not a "wakeup". > > That section also says "OSPM does not disable wake events > before setting the SLP_EN bit when entering the S5 system state." Yeah; especially the comments on patch #2 I'm not in agreement with it. How exactly do you want to handle the rest of the Sashiko comments? I suppose one option is to copy and paste them all to refute the ones I agree or disagree with. But I was thinking let you and Lukas provide comments and then I'll rev for your comments (if necessary) and then ones that I agree with Sashiko, ignore the rest.
On Tue, Apr 28, 2026 at 05:02:16PM -0500, Mario Limonciello wrote: > On 4/28/26 16:51, Bjorn Helgaas wrote: > > On Mon, Apr 27, 2026 at 03:50:18PM -0500, Mario Limonciello (AMD) wrote: > > > A few cycles ago I sent out a kernel series for using the S4 paths when > > > the system goes to S5. Some parts of it got merged, and Rafael suggested > > > to split the other parts into smaller pieces across multiple kernel cycles > > > to make bisecting easier. > > > > Thanks for posting this again. Sashiko had a few questions: > > https://sashiko.dev/#/patchset/20260427205024.254677-1-superm1%40kernel.org > > > > I didn't look at them in detail, although I did think the ACPI r6.5 > > sec 16.1.5 reference was a little bit obscure. The diagram in sec > > 16.1 certainly implies that wakeups only occur in S1-S4 and not in S5. > > > > Sec 16.1.5 does mention "Remote Start", which is completely undefined > > by the spec but searching does find sec 7.4.2.6, which clearly says > > the system requires a complete boot when awakened. Possibly a little > > misleading to refer to Remote Start as "awakening" when it's > > apparently not a "wakeup". > > > > That section also says "OSPM does not disable wake events > > before setting the SLP_EN bit when entering the S5 system state." > > Yeah; especially the comments on patch #2 I'm not in agreement with it. > > How exactly do you want to handle the rest of the Sashiko comments? I > suppose one option is to copy and paste them all to refute the ones I agree > or disagree with. > > But I was thinking let you and Lukas provide comments and then I'll rev for > your comments (if necessary) and then ones that I agree with Sashiko, ignore > the rest. It's a fair question. From my perspective I don't think it scales very well for me to go through all the Sashiko comments and figure out whether they make sense. The trivial kernel-doc comment is definitely legit. The others would take me significant legwork to evaluate.
> It's a fair question. From my perspective I don't think it scales > very well for me to go through all the Sashiko comments and figure out > whether they make sense. They are absolutely a lot of work to go through these flows and validate for me too. I'll do it; but I'd trust Lukas' thoughts first before I spend the time validating Sashiko's. > > The trivial kernel-doc comment is definitely legit. The others would > take me significant legwork to evaluate. Yup agreed on that one too, it's in my tree already for the next rev.
© 2016 - 2026 Red Hat, Inc.