From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AED80C433E0 for ; Wed, 17 Mar 2021 10:03:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7713C64F80 for ; Wed, 17 Mar 2021 10:03:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229658AbhCQKD1 (ORCPT ); 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-pci@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