Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752098AbdFOG53 (ORCPT ); Thu, 15 Jun 2017 02:57:29 -0400 Received: from mail-wr0-f173.google.com ([209.85.128.173]:36091 "EHLO mail-wr0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750794AbdFOG51 (ORCPT ); Thu, 15 Jun 2017 02:57:27 -0400 MIME-Version: 1.0 In-Reply-To: <20170613172849.GA7012@bhelgaas-glaptop.roam.corp.google.com> References: <20170613172849.GA7012@bhelgaas-glaptop.roam.corp.google.com> From: Kai-Heng Feng Date: Thu, 15 Jun 2017 14:57:24 +0800 Message-ID: Subject: Re: [PATCH] usb: host: ehci: workaround PME bug on AMD EHCI controller To: Bjorn Helgaas Cc: Alan Stern , Bjorn Helgaas , gregkh@linuxfoundation.org, USB list , linux-pci@vger.kernel.org, LKML , "Rafael J. Wysocki" , linux-pm@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1656 Lines: 47 On Wed, Jun 14, 2017 at 1:28 AM, Bjorn Helgaas 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