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@xxxxxxxxxxxxxxx> wrote: > > > > On Mon, Apr 04, 2022 at 05:41:13PM +0200, Rafael J. Wysocki wrote: > > > From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx> > > > > > > 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@xxxxxxxxx> > > > > Reviewed-by: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> > > 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.
