Re: [PATCH V3] PCI: rcar: Add the initialization of PCIe link in resume_noirq()

From: Marek Vasut <marek.vasut@gmail.com>
To: Bjorn Helgaas <helgaas@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-pci <linux-pci@vger.kernel.org>,
	Kazufumi Ikeda <kaz-ikeda@xc.jp.nec.com>,
	Gaku Inami <gaku.inami.xw@bp.renesas.com>,
	Marek Vasut <marek.vasut+renesas@gmail.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Simon Horman <horms+renesas@verge.net.au>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	stable <stable@vger.kernel.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Phil Edworthy <phil.edworthy@renesas.com>,
	Wolfram Sang <wsa@the-dreams.de>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH V3] PCI: rcar: Add the initialization of PCIe link in resume_noirq()
Date: Fri, 29 Mar 2019 10:52:05 +0100	[thread overview]
Message-ID: <8cf5b9d4-37e1-7a8d-ed44-9b978430d5f6@gmail.com> (raw)
In-Reply-To: <20190328185913.GC24180@google.com>

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:
>>   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