On 3/28/19 7:59 PM, Bjorn Helgaas wrote:
On Thu, Mar 28, 2019 at 03:59:11PM +0100, Geert Uytterhoeven wrote:
On Thu, Mar 28, 2019 at 3:18 PM Bjorn Helgaas helgaas@kernel.org wrote:
On Mon, Mar 25, 2019 at 08:43:19PM +0100, marek.vasut@gmail.com wrote:
From: Kazufumi Ikeda kaz-ikeda@xc.jp.nec.com
Reestablish the PCIe link very early in the resume process in case it went down to prevent PCI accesses from hanging the bus. Such accesses can happen early in the PCI resume process, as early as the SUSPEND_RESUME_NOIRQ step, thus the link must be reestablished in the driver resume_noirq() callback.
Fixes: e015f88c368d ("PCI: rcar: Add support for R-Car H3 to pcie-rcar")
I'm fine with the fix itself, but since e015f88c368d appeared more than two years ago in v4.5, the justification for merging this after the merge window is a little weak.
V1 of this fix was posted in November 2017, but IIRC, the series became the target of some bike-shedding...
Is there a more recent change that exposed this problem? The usual situation is that we merged something during the v5.1 merge window that caused a regression, and we're now fixing that before v5.1 final.
There are several reasons most people couldn't even run suspend/resume cycles on their systems:
- Early releases of the affected boards came with firmware revisions with non-functional PSCI system suspend,
- Preparing the PMIC for suspend required ugly assistance from i2cset in userspace, until the Linux driver learned to take care of that itself in v4.18/v4.19.
I guess the fix can survive postponing to v5.2, though...
Ok, I'll merge it to -next for v5.2, thanks.
ACK.