On Fri, Oct 25, 2019 at 1:00 AM Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > That's really strange. Your original message showed: > > xhci_hcd 0000:03:00.4: Refused to change power state, currently in D3 > xhci_hcd 0000:03:00.4: enabling device (0000 -> 0002) > > The first line is from pci_raw_set_power_state() reading PCI_PM_CTRL, > but we can't tell whether the read failed and we got ~0, or it > succeeded and we got something with just the low two bits set. Can > you print out the whole value so we can see what happened? > > The second line is from pci_enable_resources() reading PCI_COMMAND, > and it got *0*, not 0x0403 as you got from the CRS experiment. Thanks for persisting here. In more detail: pci_pm_resume_noirq - pci_pm_default_resume_early -- pci_raw_set_power_state(D0) At this point, pci_dev_wait() reads PCI_COMMAND to be 0x100403 (32-bit read) - so no wait. pci_raw_set_power_state writes to PM_CTRL and then reads it back with value 0x3. > xhci_hcd 0000:03:00.4: Refused to change power state, currently in D3 At the point of return from pci_pm_resume_noirq, an extra check I added shows that PCI_COMMAND has value 0x403 (16-bit read). 35ms later, pci_pm_resume is entered, and I checked that at this point, PCI_COMMAND has value 0. It then goes on to reach pci_enable_resources(). > xhci_hcd 0000:03:00.4: enabling device (0000 -> 0002) The change in PCI_COMMAND value is just down to timing. At the end of pci_pm_resume_noirq(), if I log PCI_COMMAND, wait 10ms, and log PCI_COMMAND again, I see it transition from 0x403 to 0. Daniel
