On Wed, Oct 23, 2024 at 10:57:35AM +0200, Stefan Eichenberger wrote: > On Tue, Oct 22, 2024 at 10:53:49AM -0500, Bjorn Helgaas wrote: > > On Mon, Oct 21, 2024 at 02:49:13PM +0200, Stefan Eichenberger wrote: > > > From: Stefan Eichenberger <stefan.eichenberger@xxxxxxxxxxx> > > > > > > The suspend/resume support is broken on the i.MX6QDL platform. This > > > patch resets the link upon resuming to recover functionality. It shares > > > most of the sequences with other i.MX devices but does not touch the > > > critical registers, which might break PCIe. This patch addresses the > > > same issue as the following downstream commit: > > > https://github.com/nxp-imx/linux-imx/commit/4e92355e1f79d225ea842511fcfd42b343b32995 > > > In comparison this patch will also reset the device if possible because > > > the downstream patch alone would still make the ath10k driver crash. > > > Without this patch suspend/resume will not work if a PCIe device is > > > connected. The kernel will hang on resume and print an error: > > > ath10k_pci 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible > ... > > The downstream commit log ("WARNING: this is not the official > > workaround; user should take own risk to use it") doesn't exactly > > inspire confidence. > > > > It sounds like this resets *endpoints*? That sounds scary and > > unexpected in suspend/resume. > > Yes, I completely agree with you, but NXP has never come up with an > "official" workaround. Our problem is that with the current > implementation, suspend/resume is completely broken when a PCIe device > is connected. With this proposed patch we at least have a working device > after resume. Even for the other i.MX devices, the driver resets the > endpoints in the resume function (imx_pcie_resume_noir -> > imx_pcie_host_init -> imx_pcie_assert_core_reset), we just do that now > for the i.MX6QDL as well. If it is more appropriate to call > imx_pcie_assert_core_reset in resume as we do for the other devices, > that would be fine with me as well. I was thinking that if we need to > reset the device anyway, we could put it into reset on suspend, as this > might save some extra power. OK, I have to admit I don't know enough about suspend/resume. Since we already do that for other i.MX platforms, maybe an endpoint reset is normal for suspend. I really don't know. In any case, if we do it for other i.MX platforms, I'm OK doing it for this one too. Bjorn
