Repository navigation
PCI: qcom: Linkdown recovery - #1236
Open
krishnachaitanya-linux wants to merge 7 commits into
Open
krishnachaitanya-linux wants to merge 7 commits into
krishnachaitanya-linux wants to merge 7 commits into
Conversation
The MSI iATU mapping is currently only cleared when the endpoint is stopped via configfs or when the host updates the MSI address/size. This avoids redundant iATU reconfiguration every time the endpoint raises an MSI interrupt. However, a fundamental reset triggered by PERST# assert/deassert resets all iATU inbound/outbound registers without going through the configfs stop path. If the host also retains the same MSI address/size after PERST# deassert, the driver never clears the stale MSI iATU mapping. It then continues using this stale mapping to raise the MSI interrupts, which can cause IOMMU faults and MSI failures on the host. Fix this by clearing the MSI iATU mapping inside dw_pcie_ep_cleanup(), which is already called as part of the PERST# assert/deassert sequence. This unmaps the MSI iATU region and sets the msi_iatu_mapped flag to false, ensuring that dw_pcie_ep_raise_msi_irq() performs a fresh iATU mapping on its next invocation, regardless of whether the host changed the MSI address/size. Fixes: 8719c64 ("PCI: dwc: ep: Cache MSI outbound iATU mapping") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Tested-by: Markus Reichelt <lkt+2023@mareichelt.com> Tested-by: Barry K. Nathan <barryn@pobox.com> Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Benjamin Boortz <bennib@mailbox.org> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Link: https://patch.msgid.link/20260729-pci-port-reset-v9-1-53570b92064d@oss.qualcomm.com
…form specific way Some host bridge devices require resetting the Root Ports in a platform specific way to recover them from error conditions such as Fatal AER errors, Link Down etc... So introduce pci_host_bridge::reset_root_port() callback and call it from pcibios_reset_secondary_bus() if available. Also, save the Root Port config space before reset and restore it afterwards. The 'reset_root_port' callback is responsible for resetting the given Root Port referenced by the 'pci_dev' pointer in a platform specific way and bring it back to the working state if possible. If any error occurs during the reset operation, relevant errno should be returned. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Tested-by: Brian Norris <briannorris@chromium.org> Tested-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Tested-by: Richard Zhu <hongxing.zhu@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260729-pci-port-reset-v9-2-53570b92064d@oss.qualcomm.com
The PCI link, when down, needs to be recovered to bring it back. But on some platforms, that cannot be done in a generic way as link recovery procedure is platform specific. So add a new API pci_host_handle_link_down() that could be called by the host bridge drivers for a specific Root Port when the link goes down. The API accepts the 'pci_dev' corresponding to the Root Port which observed the link down event. If CONFIG_PCIEAER is enabled, the API calls pcie_do_recovery() function with 'pci_channel_io_frozen' as the state. This will result in the execution of the AER Fatal error handling code. Since the link down recovery is pretty much the same as AER Fatal error handling, pcie_do_recovery() helper is reused here. AER error_detected() callback will be triggered for all of the downstream devices, but not for Root Port itself as there is nothing to do for the Root Ports in the callbacks. Finally, pci_host_reset_root_port() will be called for the Root Port, which will reset the Root Port using 'reset_root_port' callback to recover the link. Once that's done, resume message will be broadcasted to the bridge and the downstream devices, indicating successful link recovery. But if CONFIG_PCIEAER is not enabled in the kernel, only pci_host_reset_root_port() API will be called, which will in turn call pci_bus_error_reset() to just reset the Root Port as there is no way we could inform the drivers about link recovery. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Tested-by: Brian Norris <briannorris@chromium.org> Tested-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Tested-by: Richard Zhu <hongxing.zhu@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260729-pci-port-reset-v9-3-53570b92064d@oss.qualcomm.com
…ink down event The PCIe link can go down under circumstances such as the device firmware crash, link instability, etc... When that happens, the PCIe Root Port needs to be reset to make it operational again. Currently, the driver is not handling the link down event, due to which the users have to restart the machine to make PCIe link operational again. So fix it by detecting the link down event and resetting the Root Port. Since the Qcom PCIe controllers report the link down event through the 'global' IRQ, enable the link down event by setting PARF_INT_ALL_LINK_DOWN bit in PARF_INT_ALL_MASK register. In the case of the event, iterate through the available Root Ports and call pci_host_handle_link_down() API with Root Port 'pci_dev' to let the PCI core handle the link down condition. Since Qcom PCIe controllers only support one Root Port per controller instance, the API will be called only once. But the looping is necessary as there is no PCI API available to fetch the Root Port instance without the child 'pci_dev'. The API will internally call, 'pci_host_bridge::reset_root_port()' callback to reset the Root Port in a platform specific way. So implement the callback to reset the Root Port by first resetting the PCIe core, followed by reinitializing the resources and then finally starting the link again. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Tested-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Reviewed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Link: https://patch.msgid.link/20260729-pci-port-reset-v9-4-53570b92064d@oss.qualcomm.com
This Endpoint test driver doesn't need to do anything fancy in its error handlers, but just restore the config space that was saved during probe and report the correct result. This helps in making sure that the AER recovery succeeds. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260729-pci-port-reset-v9-5-53570b92064d@oss.qualcomm.com
Root Port recovery may race with a device hot-unplug. In that case, dw_pcie_wait_for_link() returns -ENODEV because no device is detected after the controller has been successfully reset. This is a valid outcome and should not cause Root Port recovery to fail. Ignore -ENODEV while continuing to propagate other link-training errors. Assisted-by: LLM Fixes: 4d88cb8 ("PCI: qcom: Implement .reset_root_port() and use for link down") Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Link: https://patch.msgid.link/20260916-topic-pcie_portrec_enodev-v1-1-5dc7bde39552@oss.qualcomm.com
After a PCIe link goes down, software may still access the BAR (MMIO) space or configuration space of devices behind that link before recovery has run. As the link is down, these accesses never complete, resulting in a storm of Completion Timeout AERs. Use the controller's ECAM blocker to drop these accesses to the PCIe address space as soon as the link-down interrupt fires, so that Completion Timeout AERs are reduced. The blocked range covers the entire address space (base 0x0, all-ones limit), since the Root Port's own DBI/iATU register space remains accessible regardless. The range is programmed once in the host init path, since the range registers are wiped by BCR reset. This leaves only the ECAM_BLOCKER_EN bit to be flipped from the link-down IRQ handler, so the blocker can be armed with a single fast register write for immediate effect. The subsequent Root Port reset re-initialises the controller, which clears the enable bit and re-programs the range for the fresh link. Some IP revisions implement the ECAM blocker registers but do not wire up the "global" interrupt used to deliver the link-down event that arms the blocker, so there is no way to enable the blocker on those platforms. Restrict blocker initialization to the post_init hooks of the IP revisions that do have a global IRQ wired up (qcom_pcie_post_init_2_3_3(), qcom_pcie_post_init_2_7_0() and qcom_pcie_post_init_2_9_0()), instead of unconditionally programming it from the common host_init path. The link-down IRQ thread's blocker-enable write to PARF_SYS_CTRL can race with a Root Port reset triggered independently through AER, which reprograms PARF_SYS_CTRL as part of reinitializing the controller. Serialize these with a per-controller mutex. Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com> Tested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> # X1E80100 CRD + ASUS PA27AC Link: https://patch.msgid.link/20260819-ecam_blocker-v2-1-e7a8fdc1c5cb@oss.qualcomm.com
Test Matrix
|
Test jobs on a37cf61 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add support for PCIe linkdown recovery patches.