All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Linux PCI <linux-pci@vger.kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Bjorn Helgaas <helgaas@kernel.org>
Subject: Re: [PATCH v1 1/2] PCI: PM: Avoid leaving devices in D0-uninitialized in pci_power_up()
Date: Fri, 8 Apr 2022 15:43:18 +0300	[thread overview]
Message-ID: <YlAt5he5B1SlORMh@lahna> (raw)
In-Reply-To: <CAJZ5v0go9hLqv6Mcc5Ko770AU7sTYJQvgyjhGJ36AO1kURUnYA@mail.gmail.com>

Hi Rafael,

On Thu, Apr 07, 2022 at 09:01:59PM +0200, Rafael J. Wysocki wrote:
> On Tue, Apr 5, 2022 at 1:45 PM Mika Westerberg
> <mika.westerberg@linux.intel.com> wrote:
> >
> > On Mon, Apr 04, 2022 at 05:41:13PM +0200, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > >
> > > In theory, pci_power_up() may leave a device in D0-uninitialized
> > > during a transition from D3cold to D0.
> > >
> > > Say, a PCIe device depending on some ACPI power resources is put into
> > > D3cold, so the power resources in question are all turned off.  Then,
> > > pci_power_up() is called to put it into D0.
> > >
> > > It first calls pci_platform_power_transition() which invokes
> > > platform_pci_set_power_state() to turn on the ACPI power resources
> > > depended on by the device and, if that is successful, it calls
> > > pci_update_current_state() to update the current_state field of
> > > the PCI device object.  If the device's configuration space is
> > > accessible at this point, which is the case if
> > > platform_pci_set_power_state() leaves it in D0-uninitialized (and
> > > there's nothing to prevent it from doing so), current_state will be
> > > set to PCI_D0 and the pci_raw_set_power_state() called subsequently
> > > will notice that the device is in D0 already and do nothing.
> > > However, that is not correct, because it may be still necessary to
> > > restore the device's BARs at this point.
> > >
> > > To address this issue, set current_state temporarily to PCI_D3hot
> > > in the cases in which pci_raw_set_power_state() may need to do more
> > > than just changing the power state of the device.
> > >
> > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> 
> Thanks, but on second thought, I'm not sure if this is the best way to
> address the issue.
> 
> Basically, pci_power_up() is called in two places, in
> pci_set_power_state() (for the transitions to D0) and in
> pci_pm_default_resume_early().  In the latter case,
> pci_restore_state() is called right after it and that covers BARs
> restoration, so nothing more needs to be done in that case.

I see.

> This means that pci_set_power_state() is the only place needing to
> restore the BARs when going into D0 from D3hot or deeper and it is
> better to move BARs restoration directly into it.  I'll update the
> series accordingly and resend.

Okay sounds good.

> I also think that the mandatory delay is not needed at all when
> pci_raw_set_power_state() is called for transitions D3cold -> D0,
> because in that case either the device has been powered up via
> platform_pci_set_power_state(), or via the bridge resume which takes
> the delay into account.

I agree.

  reply	other threads:[~2022-04-08 12:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-04 15:38 [PATCH v1 0/2]: PCI: PM: Improvements related to D3cold -> D0 transitions Rafael J. Wysocki
2022-04-04 15:41 ` [PATCH v1 1/2] PCI: PM: Avoid leaving devices in D0-uninitialized in pci_power_up() Rafael J. Wysocki
2022-04-05  9:53   ` Mika Westerberg
2022-04-07 19:01     ` Rafael J. Wysocki
2022-04-08 12:43       ` Mika Westerberg [this message]
2022-04-04 15:42 ` [PATCH v1 2/2] PCI: PM: Resume bus after putting the bridge into D0 entirely Rafael J. Wysocki
2022-04-05  9:54   ` Mika Westerberg

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=YlAt5he5B1SlORMh@lahna \
    --to=mika.westerberg@linux.intel.com \
    --cc=helgaas@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=rjw@rjwysocki.net \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.