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@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.
ACK.
--
Best regards,
Marek Vasut
