From: Mika Westerberg <firstname.lastname@example.org> To: "Rafael J. Wysocki" <email@example.com> Cc: Bjorn Helgaas <firstname.lastname@example.org>, Maximilian Luz <email@example.com>, LKML <firstname.lastname@example.org>, Linux PCI <email@example.com>, Linux PM <firstname.lastname@example.org>, Linux ACPI <email@example.com> Subject: Re: [PATCH] PCI: PM: Do not read power state in pci_enable_device_flags() Date: Wed, 17 Mar 2021 12:02:59 +0200 [thread overview] Message-ID: <20210317100259.GZ2542@lahna.fi.intel.com> (raw) In-Reply-To: <3219454.74lMxhSOWB@kreacher> On Tue, Mar 16, 2021 at 04:51:40PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <firstname.lastname@example.org> > > 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://email@example.com/ > Reported-by: Maximilian Luz <firstname.lastname@example.org> > Tested-by: Maximilian Luz <email@example.com> > Signed-off-by: Rafael J. Wysocki <firstname.lastname@example.org> Reviewed-by: Mika Westerberg <email@example.com>
next prev parent reply other threads:[~2021-03-17 10:03 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-16 15:51 Rafael J. Wysocki 2021-03-16 22:28 ` Maximilian Luz 2021-03-17 10:02 ` Mika Westerberg [this message] 2021-03-22 14:32 ` Rafael J. Wysocki 2021-03-24 15:43 ` Rafael J. Wysocki 2021-06-21 19:27 ` Salvatore Bonaccorso 2021-06-23 17:52 ` Rafael J. Wysocki
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210317100259.GZ2542@lahna.fi.intel.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH] PCI: PM: Do not read power state in pci_enable_device_flags()' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).