Re: Ryzen7 3700U xhci fails on resume from sleep

["Rafael J. Wysocki" <rafael@kernel.org>]

On Tue, Aug 27, 2019 at 4:50 AM Daniel Drake <drake@endlessm.com> wrote:
>
> On Mon, Aug 26, 2019 at 9:32 PM Mathias Nyman
> <mathias.nyman@linux.intel.com> wrote:
> > On 26.8.2019 12.29, Rafael J. Wysocki wrote:
> > > I wonder if you can reproduce this with the pm-s2idle-rework branch
> > > from linux-pm.git merged in.
> >
> > Root cause looks similar to:
> > https://bugzilla.kernel.org/show_bug.cgi?id=203885
> >
> > Mika wrote a fix for that:
> > https://lore.kernel.org/linux-pci/20190821124519.71594-1-mika.westerberg@linux.intel.com/
>
> Thanks for the suggestions. Mika's patch was already applied then
> reverted, I applied it again but there's no change.
> Also merging in pm-s2idle-rework doesn't make any difference.
>
> Any other ideas? Or comments on my findings so far?
> Given that I can't shift D0-D3-D0 reliably directly with setpci before
> loading the driver, is that indicative of a fundamental problem with
> the platform, or is my test invalid?

That depends on what exactly happens when you try to do the D0-D3-D0
with setpci.  If the device becomes unreachable (or worse) after that,
it indicates a platform issue.  It should not do any harm at the
least.

However, in principle D0-D3-D0 at the PCI level alone may not be
sufficient, because ACPI may need to be involved.

I think that PM-runtime should suspend XHCI controllers without
anything on the bus under them, so I wonder what happens if
".../power/control" is set to "on" and then to "auto" for that device,
with the driver loaded.

> Or in terms of other ways of testing the power transition outside of
> the suspend path, if a PCI dev is runtime suspended with no driver
> loaded, should Linux not be attempting to put it into D3?

PCI devices without drivers cannot be runtime-suspended at all.

Cheers,
Rafael