On 3/22/19 1:29 PM, Geert Uytterhoeven wrote:
> Hi Lorenzo, Marek,
Hi,
> On Fri, Mar 22, 2019 at 1:18 PM Lorenzo Pieralisi
> <lorenzo.pieralisi@xxxxxxx> wrote:
>> On Fri, Mar 22, 2019 at 01:09:13PM +0100, Marek Vasut wrote:
>>> On 3/22/19 12:31 PM, Lorenzo Pieralisi wrote:
>>>> On Sun, Feb 17, 2019 at 02:24:41PM +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, in the resume_noirq, thus
>>>>> the link must be reestablished in the resume_noirq callback of the
>>>>> driver.
>>>>
>>>> This looks like a fix (most likely fixing initial S2R support, please
>>>> help me chase the commit ID), should we consider it for stable kernels ?
>>>>
>>>> Without it I understand S2R is actually broken on platforms with this
>>>> host bridge.
>>> I don't think this ever worked, so it's hard to find a Fixes: commit for
>>> this.
>>
>> If we want to send it to stable kernels we have to select which versions
>> we are covering. I think the only options for a Fixes: tag are either
>> the initial S2R support commit for the platforms this driver runs on
>> or the initial driver commit that harks back to v3.16 AFAICS.
>
> This only started to become an issue when support for arm64 platforms
> was added, where PSCI may power down the SoC, right?
Wouldn't you also hit this on ARM32 LPAE ones ?
> Hence:
> Fixes: e015f88c368da1e6 ("PCI: rcar: Add support for R-Car H3 to pcie-rcar")
>
> Gr{oetje,eeting}s,
>
> Geert
>
--
Best regards,
Marek Vasut
