On Wed, Jun 14, 2017 at 1:28 AM, Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > > The lspci output [1] shows: > > 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 39) (prog-if 20 [EHCI]) > Capabilities: [c0] Power Management version 2 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) > Status: D3 NoSoftRst- PME-Enable+ DSel=0 DScale=0 PME- > Bridge: PM- B3+ > > The device claims it can assert PME# from D3hot. If it can't, that > sounds like a hardware defect that should be addressed with a quirk. > Ideally we would also have a pointer to the AMD hardware erratum. Looks like it's pretty similar to "23 USB Wake on Connect/Disconnect with Low Speed Devices" in [1]. It points to a workaround in appendix A2 from [2]. However it says this bug only effects Low Speed devices, but it actually also happens on High Speed devices. [1] https://support.amd.com/TechDocs/46837.pdf [2] https://support.amd.com/TechDocs/42413.pdf > > Is the following path involved here? > > pci_finish_runtime_suspend > target_state = pci_target_state() > if (device_may_wakup()) > if (dev->pme_support) > ... > pci_set_power_state(..., target_state) Yes, it's involved. > > If so, I would naively expect that a quirk could clear the > PCI_PM_CAP_PME_D3 and PCI_PM_CAP_PME_D3cold bits in dev->pme_support, > and pci_target_state() would then avoid selecting D3 or D3cold. But > I'm not an expert in power management. Clearing those two bits does the trick, thanks for the tip. > > Bjorn > > [1] http://marc.info/?l=linux-usb&m=149570231732519&w=2 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
