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@xxxxxxxxxx> wrote:
> > On Mon, Mar 25, 2019 at 08:43:19PM +0100, marek.vasut@xxxxxxxxx wrote:
> > > From: Kazufumi Ikeda <kaz-ikeda@xxxxxxxxxxxxx>
> > >
> > > 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:
> 1. Early releases of the affected boards came with firmware revisions with
> non-functional PSCI system suspend,
> 2. 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.
Bjorn
