Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp197225pxf; Wed, 17 Mar 2021 03:04:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxes+SsO8TQ4YqIoiM2jNqgdtJcNlPSkyJ3FStGPuNENcprFMExHIkb/lixrriXjKWYl8qK X-Received: by 2002:a17:906:170f:: with SMTP id c15mr33999344eje.358.1615975485917; Wed, 17 Mar 2021 03:04:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1615975485; cv=none; d=google.com; s=arc-20160816; b=W9ir96dq+2/8PaiBVkbtmjVaeJjRb007iD/rx+2idTCYQcnt8R6zxYZ6DVnunyXTBv aZFghlepM1BqUbZUDjWZzid30s9PbmsgLneI+khJlmN3zF1krcNxeK6xdT//npDXID2B 9RvtTSQnvoMSB+TksXRBF+hBrbeX59VpzQcOtjpRcvV0wkaHNG7PHc8anSSS85S4ilro 9qyvEu7TJTnT6QZYgK4kCVOMCGO0hnTiSPVSYRLyEafe8vlV28CQWYl7dHYaEuutUaY9 5lMKSipSpjqnkOrnIttbhjZevjxkFoplDbTp6OCyrFZu6nLSWg6IwDW0zbpeD4wtC+gP eGGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :ironport-sdr:ironport-sdr; bh=shVSaOU7UVTvPpplIiAf0L35PVUENCdE6QUdA6H1W8c=; b=MFccmQwATge7UW3+naI1X3sapzE/z9Qx9VQ9kAvxL5SccLyJVPrj5NBYoVanD0MzR5 RoJedoMzRy/8uC/MDY9HVPysYy85a0KDpRJ/PdfLWN8cMOC27H+VD2e50/Q4lpmU4gSU RRl9XFYLxmoUkBGP+dE3Tno4d/33Vsvb9y7t3Emd9Ob9nWfaNfafBBMF+vwaHAldtijX 15iQL8449ipHmUMBsUg3SNeWBV3Ph9IG/IVNH4mLZUHTEb8fNcmDUvAIMRC7veCY2hsL 7dX4pPV5Xnfv7XZdkrmkZ7KPLCJRZQQGgJjhC+YNBz28O8pqll7e+PU//6kolXlZsNuM AaYg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c14si18144343edn.71.2021.03.17.03.04.21; Wed, 17 Mar 2021 03:04:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229846AbhCQKD1 (ORCPT + 99 others); Wed, 17 Mar 2021 06:03:27 -0400 Received: from mga02.intel.com ([134.134.136.20]:36068 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229578AbhCQKDG (ORCPT ); Wed, 17 Mar 2021 06:03:06 -0400 IronPort-SDR: g896kbeENddyzL2K10byCum2y6BRviAoIM62P8wmj7vtclsr7ghZr3/RFRVRQ1yNMCT96TKGiG q+dwLw3q/dzw== X-IronPort-AV: E=McAfee;i="6000,8403,9925"; a="176562401" X-IronPort-AV: E=Sophos;i="5.81,255,1610438400"; d="scan'208";a="176562401" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Mar 2021 03:03:05 -0700 IronPort-SDR: iqCEgAM5vKX1cI4CyzlvjVLZGpGhIl64UTyUWyugrhvvbM03gLJrzJTGhJQxPs/1cOZX1GYBhg zAnWx6RKhOQw== X-IronPort-AV: E=Sophos;i="5.81,255,1610438400"; d="scan'208";a="372290793" Received: from lahna.fi.intel.com (HELO lahna) ([10.237.72.163]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Mar 2021 03:03:02 -0700 Received: by lahna (sSMTP sendmail emulation); Wed, 17 Mar 2021 12:02:59 +0200 Date: Wed, 17 Mar 2021 12:02:59 +0200 From: Mika Westerberg To: "Rafael J. Wysocki" Cc: Bjorn Helgaas , Maximilian Luz , LKML , Linux PCI , Linux PM , Linux ACPI Subject: Re: [PATCH] PCI: PM: Do not read power state in pci_enable_device_flags() Message-ID: <20210317100259.GZ2542@lahna.fi.intel.com> References: <3219454.74lMxhSOWB@kreacher> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3219454.74lMxhSOWB@kreacher> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 16, 2021 at 04:51:40PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > It should not be necessary to update the current_state field of > struct pci_dev in pci_enable_device_flags() before calling > do_pci_enable_device() for the device, because none of the > code between that point and the pci_set_power_state() call in > do_pci_enable_device() invoked later depends on it. > > Moreover, doing that is actively harmful in some cases. For example, > if the given PCI device depends on an ACPI power resource whose _STA > method initially returns 0 ("off"), but the config space of the PCI > device is accessible and the power state retrieved from the > PCI_PM_CTRL register is D0, the current_state field in the struct > pci_dev representing that device will get out of sync with the > power.state of its ACPI companion object and that will lead to > power management issues going forward. > > To avoid such issues it is better to leave the current_state value > as is until it is changed to PCI_D0 by do_pci_enable_device() as > appropriate. However, the power state of the device is not changed > to PCI_D0 if it is already enabled when pci_enable_device_flags() > gets called for it, so update its current_state in that case, but > use pci_update_current_state() covering platform PM too for that. > > Link: https://lore.kernel.org/lkml/20210314000439.3138941-1-luzmaximilian@gmail.com/ > Reported-by: Maximilian Luz > Tested-by: Maximilian Luz > Signed-off-by: Rafael J. Wysocki Reviewed-by: Mika Westerberg