Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp3523597pxb; Mon, 4 Apr 2022 19:51:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyexPgauG2SCpjqnlrgdWr70kZuukyR72OjjNFS7f9ynFkwvx8Jy7D9/PwHQJ0bfTTAAX6W X-Received: by 2002:a17:903:230c:b0:156:e47:387e with SMTP id d12-20020a170903230c00b001560e47387emr1341224plh.119.1649127069899; Mon, 04 Apr 2022 19:51:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649127069; cv=none; d=google.com; s=arc-20160816; b=a/OIWx9qaXC71OS2i3Klr3GriR+1vLk1FH7nS5T/8wry1B56QH2Op6fxQCHQ3OwSEr pWAO+cOqwV6VOlyVuejAfJJbaJr3Byo1c782nWmSDC2SUhqMkadtNeK2l8nXPudAqYdE hzgYCRrzXHRME4HoyVcdKUbX6OjHNNmrv9DDEcGZe44qCeYlImYv+HmUwNF6nI+UYA5r ZcN6L6xrO0gB+k3jAxyqTSL5bV3nsA8WUmh1Tk06A+nV9xfx2t1q/QRjuBhMZ7yOrCF/ r4XewkcVFmX6kAfilB00qDLXpaV6p1Il2/y2Lyw/flmrIf1cXft1O3uWMd3W3Xzb9BEx 8P0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=oIep2XYq0B2uZ/5/Tv7f/ROzsJKIA3tZ3wZ7fMXfeGE=; b=cobK23/YtRbwoASysTDWWyI648RxoAV5JJdU4nQywKWU6MpeppDnpJ9oJrMMTNrMlZ TEvXGDI9CbqPBfNYQ0nxVDnrK0Tem1D/NLMFcaxgBq9HR3lplgAWyymeXn+NCfp8UYgu IEoJAm/8uMhmcfXPsdT9TZgZutRELvkndKbwLGQdssgjTWnvOmm0JGlYc2sDJ++5xpvi e4G+t4nlN5HLvP9T4gzkKJHednVODD73X4/12zTqwnwy4Z1hveSe4hE4G22eq/tv9bz2 NAXo6FhQachzsgEqSArg5D23Yc4CYq99uaeo5FtOc8oBennFTDGIibNsoRE+8XwuM19+ aNUg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id g14-20020a63520e000000b003863915bbb4si11684085pgb.673.2022.04.04.19.51.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 19:51:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 9CC7541FD2F; Mon, 4 Apr 2022 18:14:37 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378656AbiDDPoj (ORCPT + 99 others); Mon, 4 Apr 2022 11:44:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55538 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1378644AbiDDPog (ORCPT ); Mon, 4 Apr 2022 11:44:36 -0400 Received: from cloudserver094114.home.pl (cloudserver094114.home.pl [79.96.170.134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9620C393F5; Mon, 4 Apr 2022 08:42:39 -0700 (PDT) Received: from localhost (127.0.0.1) (HELO v370.home.net.pl) by /usr/run/smtp (/usr/run/postfix/private/idea_relay_lmtp) via UNIX with SMTP (IdeaSmtpServer 5.0.0) id c5e46475ff8816b5; Mon, 4 Apr 2022 17:42:38 +0200 Received: from kreacher.localnet (unknown [213.134.181.62]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by v370.home.net.pl (Postfix) with ESMTPSA id 3E33F66BCD3; Mon, 4 Apr 2022 17:42:37 +0200 (CEST) From: "Rafael J. Wysocki" To: Linux PCI Cc: Linux PM , LKML , Bjorn Helgaas , Mika Westerberg Subject: [PATCH v1 1/2] PCI: PM: Avoid leaving devices in D0-uninitialized in pci_power_up() Date: Mon, 04 Apr 2022 17:41:13 +0200 Message-ID: <3623886.MHq7AAxBmi@kreacher> In-Reply-To: <4198163.ejJDZkT8p0@kreacher> References: <4198163.ejJDZkT8p0@kreacher> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" X-CLIENT-IP: 213.134.181.62 X-CLIENT-HOSTNAME: 213.134.181.62 X-VADE-SPAMSTATE: clean X-VADE-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvvddrudejvddgkeejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecujffqoffgrffnpdggtffipffknecuuegrihhlohhuthemucduhedtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffufffkjghfggfgtgesthfuredttddtjeenucfhrhhomhepfdftrghfrggvlhculfdrucghhihsohgtkhhifdcuoehrjhifsehrjhifhihsohgtkhhirdhnvghtqeenucggtffrrghtthgvrhhnpedvjeelgffhiedukedtleekkedvudfggefhgfegjefgueekjeelvefggfdvledutdenucfkphepvddufedrudefgedrudekuddriedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepvddufedrudefgedrudekuddriedvpdhhvghlohepkhhrvggrtghhvghrrdhlohgtrghlnhgvthdpmhgrihhlfhhrohhmpedftfgrfhgrvghlucflrdcuhgihshhotghkihdfuceorhhjfiesrhhjfiihshhotghkihdrnhgvtheqpdhnsggprhgtphhtthhopeehpdhrtghpthhtoheplhhinhhugidqphgtihesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdhpmhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehhvghlghgrrghssehkvghrnhgvlhdrohhrghdprhgtphhtthhopehmihhk rgdrfigvshhtvghrsggvrhhgsehlihhnuhigrdhinhhtvghlrdgtohhm X-DCC--Metrics: v370.home.net.pl 1024; Body=5 Fuz1=5 Fuz2=5 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Rafael J. Wysocki In theory, pci_power_up() may leave a device in D0-uninitialized during a transition from D3cold to D0. Say, a PCIe device depending on some ACPI power resources is put into D3cold, so the power resources in question are all turned off. Then, pci_power_up() is called to put it into D0. It first calls pci_platform_power_transition() which invokes platform_pci_set_power_state() to turn on the ACPI power resources depended on by the device and, if that is successful, it calls pci_update_current_state() to update the current_state field of the PCI device object. If the device's configuration space is accessible at this point, which is the case if platform_pci_set_power_state() leaves it in D0-uninitialized (and there's nothing to prevent it from doing so), current_state will be set to PCI_D0 and the pci_raw_set_power_state() called subsequently will notice that the device is in D0 already and do nothing. However, that is not correct, because it may be still necessary to restore the device's BARs at this point. To address this issue, set current_state temporarily to PCI_D3hot in the cases in which pci_raw_set_power_state() may need to do more than just changing the power state of the device. Signed-off-by: Rafael J. Wysocki --- drivers/pci/pci.c | 10 ++++++++++ 1 file changed, 10 insertions(+) Index: linux-pm/drivers/pci/pci.c =================================================================== --- linux-pm.orig/drivers/pci/pci.c +++ linux-pm/drivers/pci/pci.c @@ -1309,6 +1309,8 @@ static int pci_dev_wait(struct pci_dev * */ int pci_power_up(struct pci_dev *dev) { + pci_power_t old_state = dev->current_state; + pci_platform_power_transition(dev, PCI_D0); /* @@ -1325,6 +1327,14 @@ int pci_power_up(struct pci_dev *dev) pci_resume_bus(dev->subordinate); } + /* + * For transitions from D3hot or deeper and initial power-up, force + * PCI_PM_CTRL register write, D3*->D0 transition delay and BARS + * restoration. + */ + if (old_state >= PCI_D3hot) + dev->current_state = PCI_D3hot; + return pci_raw_set_power_state(dev, PCI_D0); }