From patchwork Fri Dec 14 02:52:11 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Huang, Ying" X-Patchwork-Id: 1876881 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: X-Original-To: patchwork-linux-pci@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id 95A9ADF23A for ; Fri, 14 Dec 2012 02:52:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755881Ab2LNCwT (ORCPT ); Thu, 13 Dec 2012 21:52:19 -0500 Received: from mga09.intel.com ([134.134.136.24]:9111 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755708Ab2LNCwT (ORCPT ); Thu, 13 Dec 2012 21:52:19 -0500 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 13 Dec 2012 18:51:28 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.84,277,1355126400"; d="scan'208";a="257243085" Received: from yhuang-dev.sh.intel.com ([10.239.13.178]) by orsmga002.jf.intel.com with ESMTP; 13 Dec 2012 18:52:16 -0800 From: Huang Ying To: Bjorn Helgaas Cc: linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-pm@vger.kernel.org, "Rafael J. Wysocki" , Huang Ying Subject: [PATCH] PCIe/PM: Do not suspend port if any subordinate device need PME polling Date: Fri, 14 Dec 2012 10:52:11 +0800 Message-Id: <1355453531-23348-1-git-send-email-ying.huang@intel.com> X-Mailer: git-send-email 1.7.10.4 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org In http://www.mail-archive.com/linux-usb@vger.kernel.org/msg07976.html Ulrich reported that his USB3 cardreader does not work reliably when connected to the USB3 port. It turns out that USB3 controller failed to be waken up when plugging in the USB3 cardreader. Further experiment found that the USB3 host controller can only be waken up via polling, while not via PME interrupt. But if the PCIe port that the USB3 host controller is connected is suspended, we can not poll the USB3 host controller because its config space is not accessible if the PCIe port is put into low power state. To solve the issue, the PCIe port will not be suspended if any subordinate device need PME polling. Reported-by: Ulrich Eckhardt Signed-off-by: Huang Ying Tested-by: Sarah Sharp Cc: stable@vger.kernel.org # 3.6+ Acked-by: Rafael J. Wysocki --- drivers/pci/pcie/portdrv_pci.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- a/drivers/pci/pcie/portdrv_pci.c +++ b/drivers/pci/pcie/portdrv_pci.c @@ -134,10 +134,26 @@ static int pcie_port_runtime_resume(stru return 0; } +static int pci_dev_pme_poll(struct pci_dev *pdev, void *data) +{ + int *pme_poll = data; + *pme_poll = *pme_poll || pdev->pme_poll; + return 0; +} + static int pcie_port_runtime_idle(struct device *dev) { + struct pci_dev *pdev = to_pci_dev(dev); + int pme_poll = false; + + /* + * If any subordinate device needs pme poll, we should keep + * the port in D0, because we need port in D0 to poll it. + */ + pci_walk_bus(pdev->subordinate, pci_dev_pme_poll, &pme_poll); /* Delay for a short while to prevent too frequent suspend/resume */ - pm_schedule_suspend(dev, 10); + if (!pme_poll) + pm_schedule_suspend(dev, 10); return -EBUSY; } #else