Re: [RFC PATCH] PCI: dwc: Power the controller down when hibernating

[Birk Skyum]

> Does this short-circuiting && operator cause issues during hibernation?
> [...]
> Since pme_capable is unconditionally false, pci_pwrctrl_power_off_devices()
> will force cutting auxiliary power.

That part is right. At poweroff_noirq the devices are in D3hot, the
helper would have reported PME from D3cold, and with this patch a
wake-enabled device loses its power anyway. In v2 I will call the
helper first and ignore only its verdict, not its PME result:

	if (!pci_host_common_d3cold_possible(pci->pp.bridge, &pme_capable) &&
	    pm_suspend_in_progress())
		return 0;

At freeze_noirq the devices are in D0, so the helper stops at the first
one and pme_capable stays false, which is what the image needs. I ran
this version on the Yoga Slim 7x before writing, and a hibernation with
a power-off resumes as it does with v1.

> wipes endpoint hardware state during the freeze phase, violating the
> core PM contract that thaw operates on preserved hardware state.

The reset between freeze and thaw is real, and it is the price of this
approach. pci_pm_thaw_noirq() returns the device to D0 and restores its
config space before the driver's thaw runs, so that much is covered,
and a driver whose thaw is its resume copes. NVMe did here. A driver
with a lighter thaw that expects the device's own state to be intact
would not.

I did it at freeze because I do not see how to do it at restore. The
image says the clocks, regulators and PHY of the controller are on, so
restore_noirq cannot bring them up without first taking them down, and
that means writing to a PHY that may have no power, the same kind of
access that resets the machine today. If there is a way to do this on
the restore side, or if it belongs in pcie-qcom only, I would rather do
that.

I will hold v2 until a maintainer has had a look.