Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp3479578pxb; Mon, 4 Apr 2022 18:17:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzFWRe9Wkk6B6kgpr0zGwLi+nJ8F3LajyIHx0C2L4zKq/nDJBZvITe6n/Ou0Xni/dymccpY X-Received: by 2002:a63:6dcc:0:b0:398:a0c9:7a77 with SMTP id i195-20020a636dcc000000b00398a0c97a77mr768753pgc.117.1649121477377; Mon, 04 Apr 2022 18:17:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649121477; cv=none; d=google.com; s=arc-20160816; b=pQozbsMYN+lJeJfPyywRv+77dBfIDN1QJE3pELvFe5Knz1RS/8W21VQ8kSWzEvWLbT NxnDif5ZV6P2SfzSB6L/5Ry71vXbssdEqtYqhCu/yCPMnipJQof2hmPSYbjzHoioB5tZ 3a+cuKCcCYDF5yk873ya377+fdHIrzDkshKXKnSZBl4eFZEMGVVERoUiRTNxUScz0XNu BSWeDtiVKf7Z5Ii4XYFyj65XbrfvLOIWWx1Lh3Hm4EX4VnDzL32GLa8di5tCdiXVk0Dr Q+G19iAdZdE837VQ7qyIOWcGG9yzD5JTUmuzMzS3rfF5XpnlfFDM44Z4q8pv2naap/GB 8pxQ== 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 :message-id:date:subject:cc:to:from; bh=m7uzWFBq79KKqX9v+v5+uJAp6xI8zgylumr0cOw4L5U=; b=SexHI59AlE3cwi5Pp8awkHLOUJudd3xRofTzXdxGKZJhIe+bMW+ftKvs39oodcTbjo VjyBwI9vr2P9FjvfY3hjeXKEodv9vJJydkPxehretR++zkKyPlmu4fXJbBZqStwpg03w OusXgt6nH1v54IKmyPL1bjGk7SyFMZHTq166vThAATV79cM6aPH31yUgk/mcYjHsU928 yil6QEfn+/t4EMsezzGsW3saPUl5vrAhhFGduaWkTZHtrVqvelCYrtDkJ+BwzKtsPdmv bRf/WIUDuwzVfRZbl2Je6YC2ry0a+Jiy3jyjTLUP/3tLdEjcGv2ZNvQ88pJLqckhCjQN wgkA== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id l24-20020a17090aaa9800b001bd14e03092si735426pjq.106.2022.04.04.18.17.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 18:17:57 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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 874711C6EC7; Mon, 4 Apr 2022 17:20:57 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378582AbiDDP11 (ORCPT + 99 others); Mon, 4 Apr 2022 11:27:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44460 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1378547AbiDDP1R (ORCPT ); Mon, 4 Apr 2022 11:27:17 -0400 Received: from cloudserver094114.home.pl (cloudserver094114.home.pl [79.96.170.134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 002FF1E3F2; Mon, 4 Apr 2022 08:25:20 -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 3153a6bc5aa3f00f; Mon, 4 Apr 2022 17:25:19 +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 3FFD466BCD2; Mon, 4 Apr 2022 17:25:18 +0200 (CEST) From: "Rafael J. Wysocki" To: Linux ACPI Cc: LKML , Linux PM , Linux PCI , Bjorn Helgaas , Mika Westerberg Subject: [PATCH v1 0/3] ACPI: PCI: PM: Power up PCI devices with ACPI companions upfront Date: Mon, 04 Apr 2022 17:20:30 +0200 Message-ID: <21439956.EfDdHjke4D@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: gggruggvucftvghtrhhoucdtuddrgedvvddrudejvddgkeefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecujffqoffgrffnpdggtffipffknecuuegrihhlohhuthemucduhedtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffufffkggfgtgesthfuredttddtjeenucfhrhhomhepfdftrghfrggvlhculfdrucghhihsohgtkhhifdcuoehrjhifsehrjhifhihsohgtkhhirdhnvghtqeenucggtffrrghtthgvrhhnpefhgedtffejheekgeeljeevvedtuefgffeiieejuddutdekgfejvdehueejjeetvdenucfkphepvddufedrudefgedrudekuddriedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepvddufedrudefgedrudekuddriedvpdhhvghlohepkhhrvggrtghhvghrrdhlohgtrghlnhgvthdpmhgrihhlfhhrohhmpedftfgrfhgrvghlucflrdcuhgihshhotghkihdfuceorhhjfiesrhhjfiihshhotghkihdrnhgvtheqpdhnsggprhgtphhtthhopeeipdhrtghpthhtoheplhhinhhugidqrggtphhisehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqphhmsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqphgtihesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphht thhopehhvghlghgrrghssehkvghrnhgvlhdrohhrghdprhgtphhtthhopehmihhkrgdrfigvshhtvghrsggvrhhgsehlihhnuhigrdhinhhtvghlrdgtohhm X-DCC--Metrics: v370.home.net.pl 1024; Body=6 Fuz1=6 Fuz2=6 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 Hi All, There are cases in which the power state of a PCI device depends on an ACPI power resource (or more of them) in such a way that when the given power resource is in the "off" state, the PCI device depending on it is in D3cold. On some systems, the initial state of these power resources is "off", so the kernel should not access the config space of PCI devices depending on them, until the power resources in question are turned "on", but currently that is not respected during PCI device enumeration. Namely, the PCI device enumeration code walks the entire bus and enumerates all of the devices it can find, including the ones whose initial power state in principle depends on the ACPI power resources in the "off" state. Apparently, most of the time, the config space of such devices is accessible regardless of the state of the ACPI power resource associated with the PCI device, so the device enumeration is successful, but there are two potential issues related to this behavior. First off, even if the given PCI device is accessible when the ACPI power resource depended on by it is "off", changing its configuration may confuse the platform firmware and lead to problems when the ACPI power resource in question is turned "on". Second, the PCI device may not be actually accessible at all when the ACPI power resource depended on by it is "off", in which case it won't be found during the PCI enumeration of devices. This patch series addresses that problem by turning "on" all ACPI power resources depended on by PCI devices before attempting to access the config space of those devices for the first time. The first two patches introduce the requisite machinery and the actual change of behavior is done in the last patch. Thanks!