On Tue, Sep 5, 2023 at 9:57 PM Mario Limonciello
<mario.limonciello@xxxxxxx> wrote:
>
> On 9/5/2023 05:15, Hans de Goede wrote:
> > Hi Shyam,
> >
> > On 9/5/23 12:08, Shyam Sundar S K wrote:
> >>
> >>
> >> On 8/29/2023 10:42 PM, Mario Limonciello wrote:
> >>> commit 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend")
> >>> changed pci_bridge_d3_possible() so that any vendor's PCIe ports
> >>> from modern machines (>=2015) are allowed to be put into D3.
> >>>
> >>> Iain reports that USB devices can't be used to wake a Lenovo Z13
> >>> from suspend. This is because the PCIe root port has been put
> >>> into D3 and AMD's platform can't handle USB devices waking from
> >>> a hardware sleep state in this case.
> >>>
> >>> This problem only occurs on Linux, and only when the AMD PMC driver
> >>> is utilized to put the device into a hardware sleep state. Comparing
> >>> the behavior on Windows and Linux, Windows doesn't put the root ports
> >>> into D3.
> >>>
> >>> A variety of approaches were discussed to change PCI core to handle this
> >>> case generically but no consensus was reached. To limit the scope of
> >>> effect only to the affected machines introduce a workaround into the
> >>> amd-pmc driver to only apply to the PCI root ports in affected machines
> >>> when going into hardware sleep.
> >>>
> >>> Link: https://lore.kernel.org/linux-pci/20230818193932.27187-1-mario.limonciello@xxxxxxx/
> >>> Fixes: 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend")
> >>> Reported-by: Iain Lane <iain@xxxxxxxxxxxxxxxxxxx>
> >>> Closes: https://forums.lenovo.com/t5/Ubuntu/Z13-can-t-resume-from-suspend-with-external-USB-keyboard/m-p/5217121
> >>> Signed-off-by: Mario Limonciello <mario.limonciello@xxxxxxx>
> >>
> >> See if this change can be moved to pmc-quirks.c, besides that change
> >> looks good to me. Thank you.
> >>
> >> Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@xxxxxxx>
> >
> > Thank you for the review.
> >
> > I also just replied to this series (to the cover-letter)
> > with an alternative approach based on making the
> > XHCI driver call pci_d3cold_disable() on the XHCI
> > PCIe-device on affected AMD chipsets.
> >
> > That seems like a cleaner approach to me. I wonder
> > if you have any remarks about that approach ?
> >
>
> I was thinking more about Hans' comments to the cover letter as well as
> Shyam's comments to move it into pmc-quirks.c.
>
> Perhaps it would better be conveying what's going on by having a
> dedicated step that amd-pmc calls pci_choose_state() for each PCIe
> device and checks the value against the constraints. If "any" of them
> are mismatched it could emit a message. This is a little bit of
> duplication though because drivers/acpi/x86/s2idle.c already also emits
> a similar message for some devices when pm_debug_messages is enabled.
>
> Then the special case would be for PCIe root ports that are mismatched
> the driver overrides it. If this logic change is wouldn't make sense
> for it to be moved into pmc-quirks.c.
>
> I don't think using pci_d3cold_disable() / pci_d3cold_enable() is
> correct though. If PCI core stays the same it should still be setting
> pdev->bridge_d3 to zero. The problem isn't with D3cold on the PCIe RP
> at s2didle, it's with D3hot.
Well, it's not even that.
If there were no devices expected to wake up the system from sleep
under the given Root Port, it might very well go into D3hot IIUC, so
the wakeup capability seems to be the key property here.
I need to think a bit more about this.
