Hi Bjorn,
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...
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
