[PATCH V10 2/3] PCI: handle CRS returned by device after FLR
From: helgaas@kernel.org (Bjorn Helgaas)
Date: 2017-08-23 20:01:26
Also in:
linux-arm-msm, linux-pci, lkml
On Tue, Aug 22, 2017 at 11:21:24PM -0400, Sinan Kaya wrote:
On 8/21/2017 2:00 PM, Bjorn Helgaas wrote:quoted
On Mon, Aug 21, 2017 at 09:44:09AM -0400, Sinan Kaya wrote:quoted
Hi Bjorn, On 8/18/2017 5:01 PM, Bjorn Helgaas wrote:quoted
It would still be interesting to see the lspci output. Likely <MAbort in the upstream bridge will be set even before the FLR because of aborts during enumeration. The PCI core should probably clear that after enumeration. I expect that if you manually clear it with setpci, do the lspci, do the FLR, do another lspci, you will probably see <MAbort being set by this pci_flr_wait() loop. We might want to consider clearing it here as well.Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 345 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 00002000-00002fff Memory behind bridge: 00100000-002fffff Prefetchable memory behind bridge: 0000090400000000-00000904001fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- FLR reset here with CRS to the NVMe drive. Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 345 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 00002000-00002fff Memory behind bridge: 00100000-002fffff Prefetchable memory behind bridge: 0000090400000000-00000904001fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- I don't see <MAbort getting set.
Thanks for checking. One of the many things I don't understand, I guess.