Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp879954pxb; Wed, 6 Apr 2022 03:03:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz2tvFFV8D5ts3+4LP8VlIge/KDj0ghtfcibLxK6P4qqt+Hpf6bz7CFwx2cgF1FEHUp9HUt X-Received: by 2002:a05:6a00:10d0:b0:4f7:5af4:47b6 with SMTP id d16-20020a056a0010d000b004f75af447b6mr8160429pfu.6.1649239396813; Wed, 06 Apr 2022 03:03:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649239396; cv=none; d=google.com; s=arc-20160816; b=ubq9z0c+slm+9cGtkkLKFTPK2C6U4wCZoPm8x3W6SwrZpwc5RXtR82iE9wFEElpr2+ +0wY4W6R3sptXgnZ4lmSJ4wDoef/tk9QcAFF7ZlHyW3OtnRG1R+5AsrYW33byH7pp/+k qeyK1CfE1ixmTeLBcFg8w5Dh7QkpXWNlfEfUFd2tTC2YKbhvVRK2n50DJ8j7L/7qyC5p I2oaccf3ktVesM8hg2KR2G0DqOBbUuF85r9FBLQYRQrss1wIku6Zx4TNQXq6C44j73rL Uo22U4z+9X91bDyqZlv1p+N+7dNs6pksbiYpp4iIdiOr5W7RaTDCe9kT/OajFZOBIrpU 68BQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=knCnV41xjhnnJ0VL0WEqN+kHikKWH8noX35ww6a147E=; b=iIaMnFLCbj/qjmCY069+ezwM8v0z9qGtTFWSP5OfDM0CuwUBM3O96Ny8u+UsWWw/RQ MtymcFLpadGcnU/fxR/hAuMS8Yfr22hA0ZBURwGF2zDLp1J5R9dmhOgO/VfHfiTO62Kd VN6FHqLSRUeSh+TVsx4YEl7x/0ytHaZAL3SyCZXCHsCiCTzpWLabL0atpMfJJufuObhU UZJ+LRCcaAV/jI4CLH9eRGpn8+a3OGThaaSFXiZD9HVkUCMmzLz9Fgq+75u7fsi0delg PoTQv9YBiZkFp87OihQzpxzErM32JBuDoNjfq84Pn9KhdX/kyezILQhpUTl+kdVcSBwX +nfQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id g16-20020a63dd50000000b003816043f06bsi15200483pgj.608.2022.04.06.03.03.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Apr 2022 03:03:16 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4A9CD55C791; Wed, 6 Apr 2022 01:25:09 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354635AbiDEW5k (ORCPT + 99 others); Tue, 5 Apr 2022 18:57:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55920 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349825AbiDENGH (ORCPT ); Tue, 5 Apr 2022 09:06:07 -0400 Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com [209.85.219.171]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8800175625; Tue, 5 Apr 2022 05:07:16 -0700 (PDT) Received: by mail-yb1-f171.google.com with SMTP id g9so22971564ybf.1; Tue, 05 Apr 2022 05:07:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=knCnV41xjhnnJ0VL0WEqN+kHikKWH8noX35ww6a147E=; b=O7lckBcjELkuaLNv/vx9Zk/dwxb9uNuvdTAK9RfD2UeFpLI+xa1ocEs2O+vfLgUcsy E6lMViABScXgrmVNn0UwQsQhGsBMZjx2E+J1SF4r6LWvm47xalDPaI0XJ2x+wI7/O4VW hLWnU8IchmREOD59IjWNEVY3v3AhTniApfIMW+33/WKIqoHL00Cc5FpHrYpe82q0Sw5f yYlqC0H9t+ZUIzWY9yhWmmJlA9jlW+JvfvfUm1iPBPJBlGqg44x1XmHa5Mx2jl+5l5Nx YtKYSoqyZDYZ+I2EUT8bGKLtTFar7nvRsKdGKsStiFkHJo53hRUX/Zyy2PYRi16wMF4W oWMw== X-Gm-Message-State: AOAM531oN2BMuSlLOg4c+fubzN47QHtqt6CXO/IXNgKM6WoRUnL+NEHf dOMvpaK3MYr/99JV7bZnf1StMsg1GNX/S5tJN+ueJseC X-Received: by 2002:a25:cc08:0:b0:63d:2c6d:162 with SMTP id l8-20020a25cc08000000b0063d2c6d0162mr2240396ybf.137.1649160435809; Tue, 05 Apr 2022 05:07:15 -0700 (PDT) MIME-Version: 1.0 References: <21439956.EfDdHjke4D@kreacher> In-Reply-To: From: "Rafael J. Wysocki" Date: Tue, 5 Apr 2022 14:07:03 +0200 Message-ID: Subject: Re: [PATCH v1 0/3] ACPI: PCI: PM: Power up PCI devices with ACPI companions upfront To: Mika Westerberg Cc: "Rafael J. Wysocki" , Linux ACPI , LKML , Linux PM , Linux PCI , Bjorn Helgaas Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,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 On Tue, Apr 5, 2022 at 1:45 PM Mika Westerberg wrote: > > Hi Rafael, > > On Mon, Apr 04, 2022 at 05:20:30PM +0200, Rafael J. Wysocki wrote: > > 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. > > I guess these devices do not have _PRE() method either. Personally, I haven't seen any ACPI tables containing any _PRE yet. > > 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. > > Makes sense. > > For the series, > > Reviewed-by: Mika Westerberg Thanks!