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, [email protected] wrote: > >> From: Kazufumi Ikeda <[email protected]> > >> > >> 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 > > > > Hi Marek, Kazufumi, > > Hi, > > > Apologies for the delay. > > > > Just as a clarification, when you state "in case it went down" isn't > > this supposed to happen for every suspend cycle ? Let me know and I > > will add a comment to the patch commit log. > > It does happen on every suspend/resume cycle and if you manually put a > remote endpoint into non-L0 state.
Ok I will update the log then. > >> 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. > >> > >> Signed-off-by: Kazufumi Ikeda <[email protected]> > >> Signed-off-by: Gaku Inami <[email protected]> > >> Signed-off-by: Marek Vasut <[email protected]> > >> Cc: Geert Uytterhoeven <[email protected]> > >> Cc: Phil Edworthy <[email protected]> > >> Cc: Simon Horman <[email protected]> > >> Cc: Wolfram Sang <[email protected]> > >> Cc: [email protected] > > > > 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. I will queue it next week so there is some time to think about it. Thanks, Lorenzo
