Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp4417374ybp; Mon, 14 Oct 2019 04:25:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqxYWj/luIk041ywCbfhNOUPoAT9uaCApPdKC7KOEEY1clxtDKzoWJG2zmL3UgPBt5ml4uDy X-Received: by 2002:a17:906:2ccc:: with SMTP id r12mr26598464ejr.249.1571052331063; Mon, 14 Oct 2019 04:25:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571052331; cv=none; d=google.com; s=arc-20160816; b=uM/uOoFoYjhybbEXf0sQTVMsrGueHNb2qj26NUAPb8F4B/IvM1N9i8CpqyUUnIOl58 nfER+WNE1qx3AH5gYBit/X0N2Y8EaMSQ9OlVM/NtKbVsGsEarqG5wt5BcH0iKPQJSuXQ tlwYT9yred0KsYio/Xyn4omcek1GnGAFhFQaep749aIgX4k+SMNBWnyvk57Q056iPw19 rb1VP7KylMOxTDfUewCmpLRQWOTMoDIXo4HjVI3jwPIw+9dCMEMU7NP4CLubio3gY2wX vMyOhE6RvjRcsbKdMTU2Ijz0OiWkk7Ssz7u2VF3YLi6uQUCIocsHU9Wr0Ox2xNTXCR5F o3qw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=qpQmQQzxsOzHU47a4GvK4+E+VK9w/izDCDU2UR+bn+0=; b=cDidz9pliuYEolyRD8YOHVQ2NTxMGkKsUWUNOi3T7tRZA/wWaUNTjcIy5HUHoyPldx pfbh7dg4PwVPnhta1inOjtZuuPbC1SFqYT6xwRq2O6zaWu0M0pvudXJLZgQMfkhi89HI wp476q3KUbNhF12W+A7JCgl0icQYR35u4DKtj1OO16ekGDmUmFGNIOh2UpHIog8aOPFu Rq5ewro2JHOMxk/Qg6FhhnJtAelReWNXLnn/m67Mg4dhir4sq+4ylB6cx8FvVWsdcK2s RE0jr7LdKUEgKfmuXaNYkyMhHM1brrvPiqCb+N69sH6+uDoALTlPc7wLKkTHodOh7d8V zoaQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g25si10752736ejr.409.2019.10.14.04.25.06; Mon, 14 Oct 2019 04:25:31 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729991AbfJNLZD (ORCPT + 99 others); Mon, 14 Oct 2019 07:25:03 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:54842 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726573AbfJNLZD (ORCPT ); Mon, 14 Oct 2019 07:25:03 -0400 Received: from 79.184.254.38.ipv4.supernova.orange.pl (79.184.254.38) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.292) id 4617d267eb5b2597; Mon, 14 Oct 2019 13:25:01 +0200 From: "Rafael J. Wysocki" To: Linux PCI , Daniel Drake Cc: Bjorn Helgaas , Mathias Nyman , Linux Upstreaming Team , Linux PM , Mika Westerberg , LKML Subject: [PATCH] PCI: PM: Fix pci_power_up() Date: Mon, 14 Oct 2019 13:25:00 +0200 Message-ID: <5720276.eiOaOx1Qyb@kreacher> In-Reply-To: <3118349.722IRLjr4b@kreacher> References: <20190927090202.1468-1-drake@endlessm.com> <3118349.722IRLjr4b@kreacher> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Rafael J. Wysocki There is an arbitrary difference between the system resume and runtime resume code paths for PCI devices regarding the delay to apply when switching the devices from D3cold to D0. Namely, pci_restore_standard_config() used in the runtime resume code path calls pci_set_power_state() which in turn invokes __pci_start_power_transition() to power up the device through the platform firmware and that function applies the transition delay (as per PCI Express Base Specification Revision 2.0, Section 6.6.1). However, pci_pm_default_resume_early() used in the system resume code path calls pci_power_up() which doesn't apply the delay at all and that causes issues to occur during resume from suspend-to-idle on some systems where the delay is required. Since there is no reason for that difference to exist, modify pci_power_up() to follow pci_set_power_state() more closely and invoke __pci_start_power_transition() from there to call the platform firmware to power up the device (in case that's necessary). Fixes: db288c9c5f9d ("PCI / PM: restore the original behavior of pci_set_power_state()") Reported-by: Daniel Drake Link: https://lore.kernel.org/linux-pm/CAD8Lp44TYxrMgPLkHCqF9hv6smEurMXvmmvmtyFhZ6Q4SE+dig@mail.gmail.com/T/#m21be74af263c6a34f36e0fc5c77c5449d9406925 Signed-off-by: Rafael J. Wysocki --- Daniel, please test this one. --- drivers/pci/pci.c | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) Index: linux-pm/drivers/pci/pci.c =================================================================== --- linux-pm.orig/drivers/pci/pci.c +++ linux-pm/drivers/pci/pci.c @@ -959,19 +959,6 @@ void pci_refresh_power_state(struct pci_ } /** - * pci_power_up - Put the given device into D0 forcibly - * @dev: PCI device to power up - */ -void pci_power_up(struct pci_dev *dev) -{ - if (platform_pci_power_manageable(dev)) - platform_pci_set_power_state(dev, PCI_D0); - - pci_raw_set_power_state(dev, PCI_D0); - pci_update_current_state(dev, PCI_D0); -} - -/** * pci_platform_power_transition - Use platform to change device power state * @dev: PCI device to handle. * @state: State to put the device into. @@ -1154,6 +1141,17 @@ int pci_set_power_state(struct pci_dev * EXPORT_SYMBOL(pci_set_power_state); /** + * pci_power_up - Put the given device into D0 forcibly + * @dev: PCI device to power up + */ +void pci_power_up(struct pci_dev *dev) +{ + __pci_start_power_transition(dev, PCI_D0); + pci_raw_set_power_state(dev, PCI_D0); + pci_update_current_state(dev, PCI_D0); +} + +/** * pci_choose_state - Choose the power state of a PCI device * @dev: PCI device to be suspended * @state: target sleep state for the whole system. This is the value