Re: [PATCH v7 0/4] PCI: Add support for resetting the Root Ports in a platform specific way
Hello Mani,
On Mon, May 18, 2026 at 11:51:56AM +0530, Manivannan Sadhasivam wrote:
> >
> > With the patch above. There is zero difference before/after reset, and all
> > the BAR tests pass. However, MSI/MSI-X tests still fail with:
> >
> > # pci_endpoint_test.c:143:MSI_TEST:Expected 0 (0) == ret (-110)
> > # pci_endpoint_test.c:143:MSI_TEST:Test failed for MSI1
> >
> > ETIMEDOUT.
> >
> > This suggests that pci_endpoint_test on the host side did not receive an
> > interrupt.
> >
> > I don't know why, but considering that lspci output is now (with the
> > save+restore) identical, I assume that the problem is not related to
> > the host. Unless somehow the host will use a new/different MSI address
> > after the root port has been reset, and we restore the old MSI address,
> > but looking at the code, dw_pcie_msi_init() is called by
> > dw_pcie_setup_rc(), so I would expect the MSI address to be the same.
> >
>
> Hi Niklas,
>
> When I rebased this series on top of v7.1-rc1, I ended up seeing the issue
> what
> you described here (not sure why I didn't see it earlier). So after the Root
> Port reset, MSI tests fail, but BAR tests succeed. Also, I got IOMMU faults on
> the host after endpoint triggers MSI.
>
> I investigated it and found that the MSI iATU mapping gets cleared in hw after
> LDn happens. But the host continues to use the same address/size for the
> endpoint MSI even after reset. Due to this, the existing checks in
> dw_pcie_ep_raise_msi_irq() don't pass and the stale MSI iATU mapping gets
> reused.
>
> The fix would be to clear the mapping in dw_pcie_ep_cleanup(), which gets
> called
> as part of the PERST# assert/deassert sequence post LDn and also set
> msi_iatu_mapped flag to 'false'. This will force dw_pcie_ep_raise_msi_irq() to
> use fresh iATU mapping when it gets called for the first time:
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
> b/drivers/pci/controller/dwc/pcie-designware-ep.c
> index d4dc3b24da60..4ae0e1b55f39 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> @@ -1035,6 +1035,11 @@ void dw_pcie_ep_cleanup(struct dw_pcie_ep *ep)
> {
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
>
> + if (ep->msi_iatu_mapped) {
> + dw_pcie_ep_unmap_addr(ep->epc, 0, 0, ep->msi_mem_phys);
> + ep->msi_iatu_mapped = false;
> + }
> +
> dwc_pcie_debugfs_deinit(pci);
> dw_pcie_edma_remove(pci);
> }
>
> With this change, MSI works after Root Port reset without any issues on our
> Qcom
> endpoint/host setup.
>
> Please test this change on your rockchip setup as well. You have to make sure
> that dw_pcie_ep_cleanup() is called during PERST# assert/deassert.
>
> I'm going to respin the series with this fix. If you confirm it works for you,
> then we can merge your Rockchip Root Port change.
I am happy to hear that you managed to find the root cause!
Hopefully your series can finally move forward :)
While e.g. RK3588 does have a PERST# input GPIO, so it could theoretically
add a perst_deassert()/assert() function. However, when the EPC support was
added, you did not want that, since I remember that you said that you only
wanted that for drivers that required an external refclock.
Thus, for drivers that do not require an external refclock, should we
perhaps add your suggested code in dw_pcie_ep_linkdown()?
E.g. pcie-tegra194.c does not call dw_pcie_ep_linkdown(), so I'm not
sure if we can simply move it from dw_pcie_ep_cleanup() to
dw_pcie_ep_linkdown() either...
Perhaps we need the code in both functions?
(pcie-qcom-ep.c seems to be the only function that will call both
dw_pcie_ep_linkdown() and dw_pcie_ep_cleanup().)
Kind regards,
Niklas
Re: [PATCH v7 0/4] PCI: Add support for resetting the Root Ports in a platform specific way
On Tue, Mar 17, 2026 at 12:16:47PM +0100, Niklas Cassel wrote:
> On Wed, Mar 11, 2026 at 08:44:15PM +0530, Manivannan Sadhasivam wrote:
> > On Wed, Mar 11, 2026 at 08:09:53PM +0530, Manivannan Sadhasivam wrote:
> > > On Wed, Mar 11, 2026 at 12:05:15PM +0100, Niklas Cassel wrote:
> > > > On Tue, Mar 10, 2026 at 07:31:58PM +0530, Manivannan Sadhasivam via B4
> > > > Relay wrote:
> > > > > Changes in v7:
> > > > > - Dropped Rockchip Root port reset patch due to reported issues. But
> > > > > the series
> > > > > works on other platforms as tested by others.
> > > >
> > > > Are you referring to
> > > >
> > > > ## On EP side:
> > > > # echo 0 >
> > > > /sys/kernel/config/pci_ep/controllers/a4000.pcie-ep/start && \
> > > > sleep 0.1 && echo 1 >
> > > > /sys/kernel/config/pci_ep/controllers/a4000.pcie-ep/start
> > > >
> > > > Then running pcitest only having 7 / 16 tests passed ?
> > > >
> > > > If so, isn't that a problem also for qcom?
> > > >
> > >
> > > No, tests are passing on my setup after link up.
> > >
> > > >
> > > > There is no chance that the patch:
> > > > "misc: pci_endpoint_test: Add AER error handlers"
> > > > improves things in this regard?
> > > >
> > > > Or will it simply avoid the "AER: device recovery failed" print?
> > > >
> > >
> > > Yes, as mentioned in the commit message, it just avoids the AER recovery
> > > failure
> > > message.
> > >
> >
> > I also realized that Endpoint state is not saved in all the code paths. So
> > the
> > pci_endpoint_test driver has to save/restore the state also. But it is
> > still not
> > clear why that didn't help you.
> >
> > Can you share the snapshot of the entire config space before and after reset
> > using 'lspci - -s ":01:00"'?
>
> If I don't add something like:
>
> diff --git a/drivers/misc/pci_endpoint_test.c
> b/drivers/misc/pci_endpoint_test.c
> index 1eced7a419eb..9d7ee39164d4 100644
> --- a/drivers/misc/pci_endpoint_test.c
> +++ b/drivers/misc/pci_endpoint_test.c
> @@ -1059,6 +1059,9 @@ static int pci_endpoint_test_set_irq(struct
> pci_endpoint_test *test,
> return ret;
> }
>
> + pr_info("saving PCI state (irq_type: %d)\n", req_irq_type);
> + pci_save_state(pdev);
> +
> return 0;
> }
>
> @@ -1453,6 +1456,7 @@ static pci_ers_result_t
> pci_endpoint_test_error_detected(struct pci_dev *pdev,
>
> static pci_ers_result_t pci_endpoint_test_slot_reset(struct pci_dev *pdev)
> {
> + pci_restore_state(pdev);
> return PCI_ERS_RESULT_RECOVERED;
> }
>
> On top of your patch.
>
> Then all the BAR tests + MSI and MSI-X tests fail.
>
> There is a huge difference in lspci -vvv output (as I guess is expected),
> including all BARs being marked as disabled.
>
>
> With the patch above. There is zero difference before/after reset, and all
> the BAR tests pass. However, MSI/MSI-X tests still fail with:
>
> # pci_endpoint_test.c:143:MSI_TEST:Expected 0 (0) == ret (-110)
> # pci_endpoint_test.c:143:MSI_TEST:Test failed for MSI1
>
> ETIMEDOUT.
>
> This suggests that pci_endpoint_test on the host side did not receive an
> interrupt.
>
> I don't know why, but considering that lspci output is now (with the
> save+restore) identical, I assume that the problem is not related to
> the host. Unless somehow the host will use a new/different MSI address
> after the root port has been reset, and we restore the old MSI address,
> but looking at the code, dw_pcie_msi_init() is called by
> dw_pcie_setup_rc(), so I would expect the MSI address to be the same.
>
Hi Niklas,
When I rebased this series on top of v7.1-rc1, I ended up seeing the issue what
you described here (not sure why I didn't see it earlier). So after the Root
Port reset, MSI tests fail, but BAR tests succeed. Also, I got IOMMU faults on
the host after endpoint triggers MSI.
I investigated it and found that the MSI iATU mapping gets cleared in hw after
LDn happens. But the host continues to use the same address/size for the
endpoint MSI even after reset. Due to this, the existing checks in
dw_pcie_ep_raise_msi_irq() don't pass and the stale MSI iATU mapping gets
reused.
The fix would be to clear the mapping in dw_pcie_ep_cleanup(), which gets called
as part of the PERST# assert/deassert sequence post LDn and also set
msi_iatu_mapped flag to 'false'. This will force dw_pcie_ep_raise_msi_irq() to
use fresh iATU mapping when it gets called for the first time:
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
b/drivers/pci/controller/dwc/pcie-designware-ep.c
index d4dc3b24da60..4ae0e1b55f39 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -1035,6 +1035,11 @@ void dw_pcie_ep_cleanup(struct dw_pcie_ep *ep)
{
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ if (ep->msi_iatu_mapped) {
+ dw_pcie_ep_unmap_addr(ep->epc, 0, 0, ep->msi_mem_phys);
+ ep->msi_iatu_mapped = false;
+
RE: [PATCH v7 0/4] PCI: Add support for resetting the Root Ports in a platform specific way
> -Original Message- > From: Manivannan Sadhasivam > Sent: 2026年4月14日 0:35 > To: Brian Norris ; Hongxing Zhu > > Cc: Hongxing Zhu ; > [email protected]; Bjorn Helgaas > ; Mahesh J Salgaonkar ; > Oliver O'Halloran ; Will Deacon ; > Lorenzo Pieralisi ; Krzysztof Wilczyński > ; Rob Herring ; Heiko Stuebner > ; Philipp Zabel ; > [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; Niklas > Cassel ; Wilfred Mallawa ; > Krishna Chaitanya Chundru ; Lukas > Wunner ; Wilson Ding ; Miles > Chen > Subject: Re: [PATCH v7 0/4] PCI: Add support for resetting the Root Ports in a > platform specific way > > Hi Brian, > > On Wed, Apr 08, 2026 at 06:58:34PM -0700, Brian Norris wrote: > > Hi Richard and Mani, > > > > For the record, I've been using a form of an earlier version of this > > patchset in my environment for some time now, and I've run across > > problems that *might* relate to what Richard is reporting, but I'm not > > quite sure at the moment. Details below. > > > > On Wed, Mar 25, 2026 at 07:06:49AM +, Hongxing Zhu wrote: > > > Hi Mani: > > > I've accidentally encountered a new issue based on the reset root port > patch-set. > > > After performing a few hot-reset operations, the PCIe link enters a > continuous up/down cycling pattern. > > > > > > I found that calling pci_reset_secondary_bus() first in > pcibios_reset_secondary_bus() appears to resolve this issue. > > > Have you experienced a similar problem? > > > > > > " > > > ... > > > [ 141.897701] imx6q-pcie 4c30.pcie: PCIe(LNK_STS:0x0700) > > > link up detected [ 142.086341] imx6q-pcie 4c30.pcie: PCIe Gen.3 > > > x1 link up [ 142.092038] imx6q-pcie 4c30.pcie: > > > PCIe(LNK_STS:0x0c00) link down detected ... > > > " > > > > > > Platform: i.MX95 EVK board plus local Root Ports reset supports based > on the #1 and #2 patches of v7 patch-set. > > > Notes of the logs: > > > - One Gen3 NVME device is connected. > > > - "./memtool 4c341058=0;./memtool 4c341058=1;" is used to toggle the > LTSSM_EN bit to trigger the link down. > > > - Toggle BIT6 of Bridge Control Register to trigger hot reset by > "./memtool 4c30003c=004001ff; ./memtool 4c30003c=01ff;" > > > - The Root Port reset patches works correctly at first. > > > However, after several hot-reset triggers, the link enters a repeated > down/up cycling state. > > > > > > Logs: > > > [3.553188] imx6q-pcie 4c30.pcie: host bridge > /soc/pcie@4c30 ranges: > > > [3.560308] imx6q-pcie 4c30.pcie: IO > 0x006ff0..0x006fff -> 0x00 > > > [3.568525] imx6q-pcie 4c30.pcie: MEM > 0x091000..0x091fff -> 0x001000 > > > [3.577314] imx6q-pcie 4c30.pcie: config reg[1] 0x6010 == > cpu 0x6010 > > > [3.796029] imx6q-pcie 4c30.pcie: iATU: unroll T, 128 ob, 128 ib, > align 4K, limit 1024G > > > [4.003746] imx6q-pcie 4c30.pcie: PCIe Gen.3 x1 link up > > > [4.009553] imx6q-pcie 4c30.pcie: PCI host bridge to bus :00 > > > root@imx95evk:~# > > > root@imx95evk:~# > > > root@imx95evk:~# ./memtool 4c341058=0;./memtool 4c341058=1; > Writing > > > 32-bit value 0x0 to address 0x4C341058 Writing 32-bit v > > > [ 87.265348] imx6q-pcie 4c30.pcie: PCIe(LNK_STS:0x0d01) > link down detected > > > alue 0x1 to adder > > > [ 87.273106] imx6q-pcie 4c30.pcie: Stop root bus and handle link > down > > > ss 0x4C341058 > > > [ 87.281264] pcieport :00:00.0: Recovering Root Port due to Link > Down > > > [ 87.289245] pci :01:00.0: AER: can't recover (no error_detected > callback) > > > root@imx95evk:~# [ 87.514216] imx6q-pcie 4c30.pcie: > PCIe(LNK_STS:0x0700) link up detected > > > [ 87.702968] imx6q-pcie 4c30.pcie: PCIe Gen.3 x1 link up > > > [ 87.834983] pcieport :00:00.0: Root Port has been reset > > > [ 87.840714] pcieport :00:00.0: AER: device recovery failed > > > [ 87.846592] imx6q-pcie 4c30.pcie: Rescan bus after link up is > detected > > > [ 87.855947] pcieport :00:00.0: bridge configuration invalid ([bus > 00-00]), reconfiguring > > > > I've seen this same line ("bridge configuration in
Re: [PATCH v7 0/4] PCI: Add support for resetting the Root Ports in a platform specific way
Hi Brian,
On Wed, Apr 08, 2026 at 06:58:34PM -0700, Brian Norris wrote:
> Hi Richard and Mani,
>
> For the record, I've been using a form of an earlier version of this
> patchset in my environment for some time now, and I've run across
> problems that *might* relate to what Richard is reporting, but I'm not
> quite sure at the moment. Details below.
>
> On Wed, Mar 25, 2026 at 07:06:49AM +, Hongxing Zhu wrote:
> > Hi Mani:
> > I've accidentally encountered a new issue based on the reset root port
> > patch-set.
> > After performing a few hot-reset operations, the PCIe link enters a
> > continuous up/down cycling pattern.
> >
> > I found that calling pci_reset_secondary_bus() first in
> > pcibios_reset_secondary_bus() appears to resolve this issue.
> > Have you experienced a similar problem?
> >
> > "
> > ...
> > [ 141.897701] imx6q-pcie 4c30.pcie: PCIe(LNK_STS:0x0700) link up
> > detected
> > [ 142.086341] imx6q-pcie 4c30.pcie: PCIe Gen.3 x1 link up
> > [ 142.092038] imx6q-pcie 4c30.pcie: PCIe(LNK_STS:0x0c00) link down
> > detected
> > ...
> > "
> >
> > Platform: i.MX95 EVK board plus local Root Ports reset supports based on
> > the #1 and #2 patches of v7 patch-set.
> > Notes of the logs:
> > - One Gen3 NVME device is connected.
> > - "./memtool 4c341058=0;./memtool 4c341058=1;" is used to toggle the
> > LTSSM_EN bit to trigger the link down.
> > - Toggle BIT6 of Bridge Control Register to trigger hot reset by "./memtool
> > 4c30003c=004001ff; ./memtool 4c30003c=01ff;"
> > - The Root Port reset patches works correctly at first.
> > However, after several hot-reset triggers, the link enters a repeated
> > down/up cycling state.
> >
> > Logs:
> > [3.553188] imx6q-pcie 4c30.pcie: host bridge /soc/pcie@4c30
> > ranges:
> > [3.560308] imx6q-pcie 4c30.pcie: IO
> > 0x006ff0..0x006fff -> 0x00
> > [3.568525] imx6q-pcie 4c30.pcie: MEM
> > 0x091000..0x091fff -> 0x001000
> > [3.577314] imx6q-pcie 4c30.pcie: config reg[1] 0x6010 == cpu
> > 0x6010
> > [3.796029] imx6q-pcie 4c30.pcie: iATU: unroll T, 128 ob, 128 ib,
> > align 4K, limit 1024G
> > [4.003746] imx6q-pcie 4c30.pcie: PCIe Gen.3 x1 link up
> > [4.009553] imx6q-pcie 4c30.pcie: PCI host bridge to bus :00
> > root@imx95evk:~#
> > root@imx95evk:~#
> > root@imx95evk:~# ./memtool 4c341058=0;./memtool 4c341058=1; Writing 32-bit
> > value 0x0 to address 0x4C341058
> > Writing 32-bit v
> > [ 87.265348] imx6q-pcie 4c30.pcie: PCIe(LNK_STS:0x0d01) link down
> > detected
> > alue 0x1 to adder
> > [ 87.273106] imx6q-pcie 4c30.pcie: Stop root bus and handle link down
> > ss 0x4C341058
> > [ 87.281264] pcieport :00:00.0: Recovering Root Port due to Link Down
> > [ 87.289245] pci :01:00.0: AER: can't recover (no error_detected
> > callback)
> > root@imx95evk:~# [ 87.514216] imx6q-pcie 4c30.pcie:
> > PCIe(LNK_STS:0x0700) link up detected
> > [ 87.702968] imx6q-pcie 4c30.pcie: PCIe Gen.3 x1 link up
> > [ 87.834983] pcieport :00:00.0: Root Port has been reset
> > [ 87.840714] pcieport :00:00.0: AER: device recovery failed
> > [ 87.846592] imx6q-pcie 4c30.pcie: Rescan bus after link up is
> > detected
> > [ 87.855947] pcieport :00:00.0: bridge configuration invalid ([bus
> > 00-00]), reconfiguring
>
> I've seen this same line ("bridge configuration invalid") before, and I
> believe that's because the saved state (pci_save_state(); more about
> this below) is invalid -- it contains 0 values in places where they
> should be non-zero. So when those values are restored
> (pci_restore_state()), we get confused.
>
> I believe we've pinned down one reason this invalid state occurs -- it's
> because of an automatic (mis)feature in the DesignWare PCIe hardware.
> Specifically, it's because of what the controller does during a surprise
> link-down error.
>
> From the Designware docs:
>
> "[...] during normal operation, the link might fail and go down. After
> this link-down event, the controller requests the DWC_pcie_clkrst.v
> module to hot-reset the controller. There is no difference in the
> handling of a link-down reset or a hot reset; the controller asserts
> the link_req_rst_not output requesting the DWC_pcie_clkrst.v module to
> reset the controller."
>
> In some of the adjacent documentation (and confirmed in local testing),
> it suggests that this automatic reset will also reset various DBI (i.e.,
> PCIe config space) registers. It also seems as if there's not really a
> good way to completely stop this automatic reset -- the docs mention
> some SW methods prevent the reset, but they all seem racy or incomplete.
>
> Anyway, I think this implies that patch 1 is somewhat wrong [1]. It
> includes some code like this:
>
> pci_save_state(dev);
> ret = host->reset_root_port(host, dev);
> if (ret
Re: [PATCH v7 0/4] PCI: Add support for resetting the Root Ports in a platform specific way
Hi Richard and Mani,
For the record, I've been using a form of an earlier version of this
patchset in my environment for some time now, and I've run across
problems that *might* relate to what Richard is reporting, but I'm not
quite sure at the moment. Details below.
On Wed, Mar 25, 2026 at 07:06:49AM +, Hongxing Zhu wrote:
> Hi Mani:
> I've accidentally encountered a new issue based on the reset root port
> patch-set.
> After performing a few hot-reset operations, the PCIe link enters a
> continuous up/down cycling pattern.
>
> I found that calling pci_reset_secondary_bus() first in
> pcibios_reset_secondary_bus() appears to resolve this issue.
> Have you experienced a similar problem?
>
> "
> ...
> [ 141.897701] imx6q-pcie 4c30.pcie: PCIe(LNK_STS:0x0700) link up
> detected
> [ 142.086341] imx6q-pcie 4c30.pcie: PCIe Gen.3 x1 link up
> [ 142.092038] imx6q-pcie 4c30.pcie: PCIe(LNK_STS:0x0c00) link down
> detected
> ...
> "
>
> Platform: i.MX95 EVK board plus local Root Ports reset supports based on the
> #1 and #2 patches of v7 patch-set.
> Notes of the logs:
> - One Gen3 NVME device is connected.
> - "./memtool 4c341058=0;./memtool 4c341058=1;" is used to toggle the LTSSM_EN
> bit to trigger the link down.
> - Toggle BIT6 of Bridge Control Register to trigger hot reset by "./memtool
> 4c30003c=004001ff; ./memtool 4c30003c=01ff;"
> - The Root Port reset patches works correctly at first.
> However, after several hot-reset triggers, the link enters a repeated down/up
> cycling state.
>
> Logs:
> [3.553188] imx6q-pcie 4c30.pcie: host bridge /soc/pcie@4c30
> ranges:
> [3.560308] imx6q-pcie 4c30.pcie: IO 0x006ff0..0x006fff
> -> 0x00
> [3.568525] imx6q-pcie 4c30.pcie: MEM 0x091000..0x091fff
> -> 0x001000
> [3.577314] imx6q-pcie 4c30.pcie: config reg[1] 0x6010 == cpu
> 0x6010
> [3.796029] imx6q-pcie 4c30.pcie: iATU: unroll T, 128 ob, 128 ib,
> align 4K, limit 1024G
> [4.003746] imx6q-pcie 4c30.pcie: PCIe Gen.3 x1 link up
> [4.009553] imx6q-pcie 4c30.pcie: PCI host bridge to bus :00
> root@imx95evk:~#
> root@imx95evk:~#
> root@imx95evk:~# ./memtool 4c341058=0;./memtool 4c341058=1; Writing 32-bit
> value 0x0 to address 0x4C341058
> Writing 32-bit v
> [ 87.265348] imx6q-pcie 4c30.pcie: PCIe(LNK_STS:0x0d01) link down
> detected
> alue 0x1 to adder
> [ 87.273106] imx6q-pcie 4c30.pcie: Stop root bus and handle link down
> ss 0x4C341058
> [ 87.281264] pcieport :00:00.0: Recovering Root Port due to Link Down
> [ 87.289245] pci :01:00.0: AER: can't recover (no error_detected
> callback)
> root@imx95evk:~# [ 87.514216] imx6q-pcie 4c30.pcie:
> PCIe(LNK_STS:0x0700) link up detected
> [ 87.702968] imx6q-pcie 4c30.pcie: PCIe Gen.3 x1 link up
> [ 87.834983] pcieport :00:00.0: Root Port has been reset
> [ 87.840714] pcieport :00:00.0: AER: device recovery failed
> [ 87.846592] imx6q-pcie 4c30.pcie: Rescan bus after link up is detected
> [ 87.855947] pcieport :00:00.0: bridge configuration invalid ([bus
> 00-00]), reconfiguring
I've seen this same line ("bridge configuration invalid") before, and I
believe that's because the saved state (pci_save_state(); more about
this below) is invalid -- it contains 0 values in places where they
should be non-zero. So when those values are restored
(pci_restore_state()), we get confused.
I believe we've pinned down one reason this invalid state occurs -- it's
because of an automatic (mis)feature in the DesignWare PCIe hardware.
Specifically, it's because of what the controller does during a surprise
link-down error.
>From the Designware docs:
"[...] during normal operation, the link might fail and go down. After
this link-down event, the controller requests the DWC_pcie_clkrst.v
module to hot-reset the controller. There is no difference in the
handling of a link-down reset or a hot reset; the controller asserts
the link_req_rst_not output requesting the DWC_pcie_clkrst.v module to
reset the controller."
In some of the adjacent documentation (and confirmed in local testing),
it suggests that this automatic reset will also reset various DBI (i.e.,
PCIe config space) registers. It also seems as if there's not really a
good way to completely stop this automatic reset -- the docs mention
some SW methods prevent the reset, but they all seem racy or incomplete.
Anyway, I think this implies that patch 1 is somewhat wrong [1]. It
includes some code like this:
pci_save_state(dev);
ret = host->reset_root_port(host, dev);
if (ret)
pci_err(dev, "Failed to reset Root Port: %d\n", ret);
else
/* Now restore it on success */
pci_restore_state(dev);
That first line (pci_save_state()) is prone to saving invalid state,
depending
RE: [PATCH v7 0/4] PCI: Add support for resetting the Root Ports in a platform specific way
Hi Mani: I've accidentally encountered a new issue based on the reset root port patch-set. After performing a few hot-reset operations, the PCIe link enters a continuous up/down cycling pattern. I found that calling pci_reset_secondary_bus() first in pcibios_reset_secondary_bus() appears to resolve this issue. Have you experienced a similar problem? " ... [ 141.897701] imx6q-pcie 4c30.pcie: PCIe(LNK_STS:0x0700) link up detected [ 142.086341] imx6q-pcie 4c30.pcie: PCIe Gen.3 x1 link up [ 142.092038] imx6q-pcie 4c30.pcie: PCIe(LNK_STS:0x0c00) link down detected ... " Platform: i.MX95 EVK board plus local Root Ports reset supports based on the #1 and #2 patches of v7 patch-set. Notes of the logs: - One Gen3 NVME device is connected. - "./memtool 4c341058=0;./memtool 4c341058=1;" is used to toggle the LTSSM_EN bit to trigger the link down. - Toggle BIT6 of Bridge Control Register to trigger hot reset by "./memtool 4c30003c=004001ff; ./memtool 4c30003c=01ff;" - The Root Port reset patches works correctly at first. However, after several hot-reset triggers, the link enters a repeated down/up cycling state. Logs: [3.553188] imx6q-pcie 4c30.pcie: host bridge /soc/pcie@4c30 ranges: [3.560308] imx6q-pcie 4c30.pcie: IO 0x006ff0..0x006fff -> 0x00 [3.568525] imx6q-pcie 4c30.pcie: MEM 0x091000..0x091fff -> 0x001000 [3.577314] imx6q-pcie 4c30.pcie: config reg[1] 0x6010 == cpu 0x6010 [3.796029] imx6q-pcie 4c30.pcie: iATU: unroll T, 128 ob, 128 ib, align 4K, limit 1024G [4.003746] imx6q-pcie 4c30.pcie: PCIe Gen.3 x1 link up [4.009553] imx6q-pcie 4c30.pcie: PCI host bridge to bus :00 root@imx95evk:~# root@imx95evk:~# root@imx95evk:~# ./memtool 4c341058=0;./memtool 4c341058=1; Writing 32-bit value 0x0 to address 0x4C341058 Writing 32-bit v [ 87.265348] imx6q-pcie 4c30.pcie: PCIe(LNK_STS:0x0d01) link down detected alue 0x1 to adder [ 87.273106] imx6q-pcie 4c30.pcie: Stop root bus and handle link down ss 0x4C341058 [ 87.281264] pcieport :00:00.0: Recovering Root Port due to Link Down [ 87.289245] pci :01:00.0: AER: can't recover (no error_detected callback) root@imx95evk:~# [ 87.514216] imx6q-pcie 4c30.pcie: PCIe(LNK_STS:0x0700) link up detected [ 87.702968] imx6q-pcie 4c30.pcie: PCIe Gen.3 x1 link up [ 87.834983] pcieport :00:00.0: Root Port has been reset [ 87.840714] pcieport :00:00.0: AER: device recovery failed [ 87.846592] imx6q-pcie 4c30.pcie: Rescan bus after link up is detected [ 87.855947] pcieport :00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring [ 87.864423] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01 root@imx95evk:~# root@imx95evk:~# cat /proc/interrupts | grep lnk; 273: 2 0 0 0 0 0GICv3 342 Level PCIe PME, lnk_notify root@imx95evk:~# root@imx95evk:~# root@imx95evk:~# ./memtool 4c30003c=004001ff; ./memtool 4c30003c=01ff; Writing 32-bit va [ 107.028086] imx6q-pcie 4c30.pcie: PCIe(LNK_STS:0x0d00) link down detected lue 0x4001FF to a [ 107.037018] imx6q-pcie 4c30.pcie: Stop root bus and handle link down ddress 0x4C30003C [ 107.045137] pcieport :00:00.0: Recovering Root Port due to Link Down Writing 32-bit [ 107.053332] pci :01:00.0: AER: can't recover (no error_detected callback) value 0x1FF to address 0x4C30003C root@imx95evk:~# [ 107.282146] imx6q-pcie 4c30.pcie: PCIe(LNK_STS:0x0700) link up detected [ 107.470801] imx6q-pcie 4c30.pcie: PCIe Gen.3 x1 link up [ 107.602823] pcieport :00:00.0: Root Port has been reset [ 107.608601] pcieport :00:00.0: AER: device recovery failed [ 107.614497] imx6q-pcie 4c30.pcie: Rescan bus after link up is detected [ 107.623805] pcieport :00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring [ 107.632281] pci_bus :01: busn_res: [bus 01] end is updated to 01 root@imx95evk:~# root@imx95evk:~# cat /proc/interrupts | grep lnk; 273: 4 0 0 0 0 0GICv3 342 Level PCIe PME, lnk_notify root@imx95evk:~# root@imx95evk:~# ./memtool 4c30003c=004001ff; ./memtool 4c30003c=01ff; Writing 32-bit va [ 133.424041] imx6q-pcie 4c30.pcie: PCIe(LNK_STS:0x0d00) link down detected lue 0x4001FF to a [ 133.432954] imx6q-pcie 4c30.pcie: Stop root bus and handle link down ddress 0x4C30003C [ 133.441106] pcieport :00:00.0: Recovering Root Port due to Link Down Writing 32-bit [ 133.449309] pci :01:00.0: AER: can't recover (no error_detected callback) value 0x1FF to address 0x4C30003C root@imx95evk:~# [ 133.677824] imx6q-pcie 4c30.pcie: PCIe(LNK_STS:0x0700) link up detected [ 133.870414] imx6q-pcie 4c30.pcie: PCIe Gen.3 x1 link up [ 134.002534] pcieport :00:00.0: Root Port has been reset [ 134.0
Re: [PATCH v7 0/4] PCI: Add support for resetting the Root Ports in a platform specific way
On Tue, Mar 17, 2026 at 12:17:19PM +0100, Niklas Cassel wrote:
>
> I will be very busy for a few weeks, so I don't have time to debug this.
> If anyone wants to debug this on rk3588, I'm attaching the patches for
> this new feature for rk3588 that can be applied on top of this series.
For what it is worth, attaching an improved patch for rk3588 that does not
require any revert.
Kind regards,
Niklas
>From a69679430750d7371e65e1b209059803cea2f5de Mon Sep 17 00:00:00 2001
From: Wilfred Mallawa
Date: Tue, 17 Mar 2026 09:30:57 +0100
Subject: [PATCH] PCI: dw-rockchip: Add support to reset Root Port upon link
down event
The PCIe link may go down in cases like firmware crashes or unstable
connections. When this occurs, the PCIe Root Port must be reset to restore
the functionality. However, the current driver lacks link down handling,
forcing users to reboot the system to recover.
This patch implements the `reset_root_port` callback for link down handling
for Rockchip DWC PCIe host controller. In which, the RC is reset,
reconfigured and link training initiated to recover from the link down
event.
This also by extension fixes issues with sysfs initiated bus resets. In
that, currently, when a sysfs initiated bus reset is issued, the endpoint
device is non-functional after (may link up with downgraded link status).
With the link down handling support, a sysfs initiated bus reset works as
intended. Testing conducted on a ROCK5B board with an M.2 NVMe drive.
Signed-off-by: Wilfred Mallawa
---
drivers/pci/controller/dwc/Kconfig| 1 +
drivers/pci/controller/dwc/pcie-dw-rockchip.c | 134 +-
2 files changed, 132 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/Kconfig
b/drivers/pci/controller/dwc/Kconfig
index d0aa031397fa..ecaf79da843b 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -361,6 +361,7 @@ config PCIE_ROCKCHIP_DW_HOST
depends on OF
select PCIE_DW_HOST
select PCIE_ROCKCHIP_DW
+ select PCI_HOST_COMMON
help
Enables support for the DesignWare PCIe controller in the
Rockchip SoC (except RK3399) to work in host mode.
diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
index 8db27199cfa6..988d98effcd7 100644
--- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
+++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
@@ -24,6 +24,7 @@
#include
#include "../../pci.h"
+#include "../pci-host-common.h"
#include "pcie-designware.h"
/*
@@ -105,6 +106,9 @@ struct rockchip_pcie_of_data {
const struct pci_epc_features *epc_features;
};
+static int rockchip_pcie_rc_reset_root_port(struct pci_host_bridge *bridge,
+ struct pci_dev *pdev);
+
static int rockchip_pcie_readl_apb(struct rockchip_pcie *rockchip, u32 reg)
{
return readl_relaxed(rockchip->apb_base + reg);
@@ -325,6 +329,7 @@ static int rockchip_pcie_host_init(struct dw_pcie_rp *pp)
rockchip_pcie_configure_l1ss(pci);
rockchip_pcie_enable_l0s(pci);
+ pp->bridge->reset_root_port = rockchip_pcie_rc_reset_root_port;
/* Disable Root Ports BAR0 and BAR1 as they report bogus size */
dw_pcie_writel_dbi2(pci, PCI_BASE_ADDRESS_0, 0x0);
@@ -523,6 +528,32 @@ static const struct dw_pcie_ops dw_pcie_ops = {
.get_ltssm = rockchip_pcie_get_ltssm,
};
+static irqreturn_t rockchip_pcie_rc_sys_irq_thread(int irq, void *arg)
+{
+ struct rockchip_pcie *rockchip = arg;
+ struct dw_pcie *pci = &rockchip->pci;
+ struct dw_pcie_rp *pp = &pci->pp;
+ struct device *dev = pci->dev;
+ struct pci_dev *port;
+ u32 reg;
+
+ reg = rockchip_pcie_readl_apb(rockchip, PCIE_CLIENT_INTR_STATUS_MISC);
+ rockchip_pcie_writel_apb(rockchip, reg, PCIE_CLIENT_INTR_STATUS_MISC);
+
+ dev_dbg(dev, "PCIE_CLIENT_INTR_STATUS_MISC: %#x\n", reg);
+ dev_dbg(dev, "LTSSM_STATUS: %#x\n",
rockchip_pcie_get_ltssm_reg(rockchip));
+
+ if (reg & PCIE_LINK_REQ_RST_NOT_INT) {
+ dev_dbg(dev, "hot reset or link-down reset\n");
+ for_each_pci_bridge(port, pp->bridge->bus) {
+ if (pci_pcie_type(port) == PCI_EXP_TYPE_ROOT_PORT)
+ pci_host_handle_link_down(port);
+ }
+ }
+
+ return IRQ_HANDLED;
+}
+
static irqreturn_t rockchip_pcie_ep_sys_irq_thread(int irq, void *arg)
{
struct rockchip_pcie *rockchip = arg;
@@ -555,14 +586,29 @@ static irqreturn_t rockchip_pcie_ep_sys_irq_thread(int
irq, void *arg)
return IRQ_HANDLED;
}
-static int rockchip_pcie_configure_rc(struct rockchip_pcie *rockchip)
+static int rockchip_pcie_configure_rc(struct platform_device *pdev,
+ struct rockchip_pcie *rockchip)
{
+ struct device *dev = &pdev->dev;
struct dw_pcie_rp *pp;
+ int irq, ret;
Re: [PATCH v7 0/4] PCI: Add support for resetting the Root Ports in a platform specific way
On Wed, Mar 11, 2026 at 08:44:15PM +0530, Manivannan Sadhasivam wrote:
> On Wed, Mar 11, 2026 at 08:09:53PM +0530, Manivannan Sadhasivam wrote:
> > On Wed, Mar 11, 2026 at 12:05:15PM +0100, Niklas Cassel wrote:
> > > On Tue, Mar 10, 2026 at 07:31:58PM +0530, Manivannan Sadhasivam via B4
> > > Relay wrote:
> > > > Changes in v7:
> > > > - Dropped Rockchip Root port reset patch due to reported issues. But
> > > > the series
> > > > works on other platforms as tested by others.
> > >
> > > Are you referring to
> > >
> > > ## On EP side:
> > > # echo 0 > /sys/kernel/config/pci_ep/controllers/a4000.pcie-ep/start
> > > && \
> > > sleep 0.1 && echo 1 >
> > > /sys/kernel/config/pci_ep/controllers/a4000.pcie-ep/start
> > >
> > > Then running pcitest only having 7 / 16 tests passed ?
> > >
> > > If so, isn't that a problem also for qcom?
> > >
> >
> > No, tests are passing on my setup after link up.
> >
> > >
> > > There is no chance that the patch:
> > > "misc: pci_endpoint_test: Add AER error handlers"
> > > improves things in this regard?
> > >
> > > Or will it simply avoid the "AER: device recovery failed" print?
> > >
> >
> > Yes, as mentioned in the commit message, it just avoids the AER recovery
> > failure
> > message.
> >
>
> I also realized that Endpoint state is not saved in all the code paths. So the
> pci_endpoint_test driver has to save/restore the state also. But it is still
> not
> clear why that didn't help you.
>
> Can you share the snapshot of the entire config space before and after reset
> using 'lspci - -s ":01:00"'?
If I don't add something like:
diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index 1eced7a419eb..9d7ee39164d4 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -1059,6 +1059,9 @@ static int pci_endpoint_test_set_irq(struct
pci_endpoint_test *test,
return ret;
}
+ pr_info("saving PCI state (irq_type: %d)\n", req_irq_type);
+ pci_save_state(pdev);
+
return 0;
}
@@ -1453,6 +1456,7 @@ static pci_ers_result_t
pci_endpoint_test_error_detected(struct pci_dev *pdev,
static pci_ers_result_t pci_endpoint_test_slot_reset(struct pci_dev *pdev)
{
+ pci_restore_state(pdev);
return PCI_ERS_RESULT_RECOVERED;
}
On top of your patch.
Then all the BAR tests + MSI and MSI-X tests fail.
There is a huge difference in lspci -vvv output (as I guess is expected),
including all BARs being marked as disabled.
With the patch above. There is zero difference before/after reset, and all
the BAR tests pass. However, MSI/MSI-X tests still fail with:
# pci_endpoint_test.c:143:MSI_TEST:Expected 0 (0) == ret (-110)
# pci_endpoint_test.c:143:MSI_TEST:Test failed for MSI1
ETIMEDOUT.
This suggests that pci_endpoint_test on the host side did not receive an
interrupt.
I don't know why, but considering that lspci output is now (with the
save+restore) identical, I assume that the problem is not related to
the host. Unless somehow the host will use a new/different MSI address
after the root port has been reset, and we restore the old MSI address,
but looking at the code, dw_pcie_msi_init() is called by
dw_pcie_setup_rc(), so I would expect the MSI address to be the same.
I will be very busy for a few weeks, so I don't have time to debug this.
If anyone wants to debug this on rk3588, I'm attaching the patches for
this new feature for rk3588 that can be applied on top of this series.
Personally, I'm fine with this series getting merged even though this
new feature will only be supported by the QCOM driver.
But, I don't understand how e.g. pci endpoint test can work on QCOM
platforms, after the root port has been reset, without something like
the save/restore diff above.
Kind regards,
Niklas
>From c6416291bdbe2a3964b60183492208b41208f5a0 Mon Sep 17 00:00:00 2001
From: Niklas Cassel
Date: Tue, 17 Mar 2026 09:59:09 +0100
Subject: [PATCH 1/2] Revert "PCI: dw-rockchip: Simplify regulator setup with
devm_regulator_get_enable_optional()"
This reverts commit c930b10f17c03858cfe19b9873ba5240128b4d1b.
---
drivers/pci/controller/dwc/pcie-dw-rockchip.c | 23 ++-
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
index 8db27199cfa6..bec42fe646d8 100644
--- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
+++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
@@ -95,6 +95,7 @@ struct rockchip_pcie {
unsigned int clk_cnt;
struct reset_control *rst;
struct gpio_desc *rst_gpio;
+ struct regulator *vpcie3v3;
struct irq_domain *irq_domain;
const struct rockchip_pcie_of_data *data;
bool supports_clkreq;
@@ -673,15 +674,22 @@ static int rockchip_pcie_probe(struct platform_device
*pdev)
return ret;
/* DON'T MOVE ME: must be enable before PHY init */
-
Re: [PATCH v7 0/4] PCI: Add support for resetting the Root Ports in a platform specific way
On Wed, Mar 11, 2026 at 08:09:53PM +0530, Manivannan Sadhasivam wrote: > On Wed, Mar 11, 2026 at 12:05:15PM +0100, Niklas Cassel wrote: > > On Tue, Mar 10, 2026 at 07:31:58PM +0530, Manivannan Sadhasivam via B4 > > Relay wrote: > > > Changes in v7: > > > - Dropped Rockchip Root port reset patch due to reported issues. But the > > > series > > > works on other platforms as tested by others. > > > > Are you referring to > > > > ## On EP side: > > # echo 0 > /sys/kernel/config/pci_ep/controllers/a4000.pcie-ep/start && > > \ > > sleep 0.1 && echo 1 > > > /sys/kernel/config/pci_ep/controllers/a4000.pcie-ep/start > > > > Then running pcitest only having 7 / 16 tests passed ? > > > > If so, isn't that a problem also for qcom? > > > > No, tests are passing on my setup after link up. > > > > > There is no chance that the patch: > > "misc: pci_endpoint_test: Add AER error handlers" > > improves things in this regard? > > > > Or will it simply avoid the "AER: device recovery failed" print? > > > > Yes, as mentioned in the commit message, it just avoids the AER recovery > failure > message. > I also realized that Endpoint state is not saved in all the code paths. So the pci_endpoint_test driver has to save/restore the state also. But it is still not clear why that didn't help you. Can you share the snapshot of the entire config space before and after reset using 'lspci - -s ":01:00"'? - Mani -- மணிவண்ணன் சதாசிவம்
Re: [PATCH v7 0/4] PCI: Add support for resetting the Root Ports in a platform specific way
On Wed, Mar 11, 2026 at 12:05:15PM +0100, Niklas Cassel wrote: > On Tue, Mar 10, 2026 at 07:31:58PM +0530, Manivannan Sadhasivam via B4 Relay > wrote: > > Changes in v7: > > - Dropped Rockchip Root port reset patch due to reported issues. But the > > series > > works on other platforms as tested by others. > > Are you referring to > > ## On EP side: > # echo 0 > /sys/kernel/config/pci_ep/controllers/a4000.pcie-ep/start && \ > sleep 0.1 && echo 1 > > /sys/kernel/config/pci_ep/controllers/a4000.pcie-ep/start > > Then running pcitest only having 7 / 16 tests passed ? > > If so, isn't that a problem also for qcom? > No, tests are passing on my setup after link up. > > There is no chance that the patch: > "misc: pci_endpoint_test: Add AER error handlers" > improves things in this regard? > > Or will it simply avoid the "AER: device recovery failed" print? > Yes, as mentioned in the commit message, it just avoids the AER recovery failure message. - Mani -- மணிவண்ணன் சதாசிவம்
Re: [PATCH v7 0/4] PCI: Add support for resetting the Root Ports in a platform specific way
On Tue, Mar 10, 2026 at 07:31:58PM +0530, Manivannan Sadhasivam via B4 Relay wrote: > Changes in v7: > - Dropped Rockchip Root port reset patch due to reported issues. But the > series > works on other platforms as tested by others. Are you referring to ## On EP side: # echo 0 > /sys/kernel/config/pci_ep/controllers/a4000.pcie-ep/start && \ sleep 0.1 && echo 1 > /sys/kernel/config/pci_ep/controllers/a4000.pcie-ep/start Then running pcitest only having 7 / 16 tests passed ? If so, isn't that a problem also for qcom? There is no chance that the patch: "misc: pci_endpoint_test: Add AER error handlers" improves things in this regard? Or will it simply avoid the "AER: device recovery failed" print? Kind regards, Niklas
Re: [PATCH v7 0/4] PCI: Add support for resetting the Root Ports in a platform specific way
On 3/10/2026 7:31 PM, Manivannan Sadhasivam via B4 Relay wrote:
Hi,
Currently, in the event of AER/DPC, PCI core will try to reset the slot (Root
Port) and its subordinate devices by invoking bridge control reset and FLR. But
in some cases like AER Fatal error, it might be necessary to reset the Root
Ports using the PCI host bridge drivers in a platform specific way (as indicated
by the TODO in the pcie_do_recovery() function in drivers/pci/pcie/err.c).
Otherwise, the PCI link won't be recovered successfully.
So this series adds a new callback 'pci_host_bridge::reset_root_port' for the
host bridge drivers to reset the Root Port when a fatal error happens.
Also, this series allows the host bridge drivers to handle PCI link down event
by resetting the Root Ports and recovering the bus. This is accomplished by the
help of the new 'pci_host_handle_link_down()' API. Host bridge drivers are
expected to call this API (preferrably from a threaded IRQ handler) with
relevant Root Port 'pci_dev' when a link down event is detected for the port.
The API will reuse the pcie_do_recovery() function to recover the link if AER
support is enabled, otherwise it will directly call the reset_root_port()
callback of the host bridge driver (if exists).
For reference, I've modified the pcie-qcom driver to call
pci_host_handle_link_down() API with Root Port 'pci_dev' after receiving the
LDn global_irq event and populated 'pci_host_bridge::reset_root_port()'
callback to reset the Root Ports.
Testing
---
Tested on Qcom Lemans AU Ride platform with Host and EP SoCs connected over PCIe
link. Simulated the LDn by disabling LTSSM_EN on the EP and I could verify that
the link was getting recovered successfully.
Changes in v7:
- Dropped Rockchip Root port reset patch due to reported issues. But the series
works on other platforms as tested by others.
- Added pci_{lock/unlock}_rescan_remove() to guard pci_bus_error_reset() as the
device could be removed in-between due to Native hotplug interrupt.
- Rebased on top of v7.0-rc1
- Link to v6:
https://lore.kernel.org/r/[email protected]
Changes in v6:
- Incorporated the patch:
https://lore.kernel.org/all/[email protected]/
- Link to v5:
https://lore.kernel.org/r/[email protected]
Changes in v5:
* Reworked the pci_host_handle_link_down() to accept Root Port instead of
resetting all Root Ports in the event of link down.
* Renamed 'reset_slot' to 'reset_root_port' to avoid confusion as both terms
were used interchangibly and the series is intended to reset Root Port only.
* Added the Rockchip driver change to this series.
* Dropped the applied patches and review/tested tags due to rework.
* Rebased on top of v6.16-rc1.
Changes in v4:
- Handled link down first in the irq handler
- Updated ICC & OPP bandwidth after link up in reset_slot() callback
- Link to v3:
https://lore.kernel.org/r/[email protected]
Changes in v3:
- Made the pci-host-common driver as a common library for host controller
drivers
- Moved the reset slot code to pci-host-common library
- Link to v2:
https://lore.kernel.org/r/[email protected]
Changes in v2:
- Moved calling reset_slot() callback from pcie_do_recovery() to
pcibios_reset_secondary_bus()
- Link to v1:
https://lore.kernel.org/r/[email protected]
Signed-off-by: Manivannan Sadhasivam
For entire series,
Reviewed-by: Krishna Chaitanya Chundru
- Krishna Chaitanya.
---
Manivannan Sadhasivam (4):
PCI/ERR: Add support for resetting the Root Ports in a platform specific
way
PCI: host-common: Add link down handling for Root Ports
PCI: qcom: Add support for resetting the Root Port due to link down event
misc: pci_endpoint_test: Add AER error handlers
drivers/misc/pci_endpoint_test.c | 20 +
drivers/pci/controller/dwc/pcie-qcom.c | 143 ++-
drivers/pci/controller/pci-host-common.c | 35
drivers/pci/controller/pci-host-common.h | 1 +
drivers/pci/pci.c| 21 +
drivers/pci/pcie/err.c | 6 +-
include/linux/pci.h | 1 +
7 files changed, 221 insertions(+), 6 deletions(-)
---
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
change-id: 20250715-pci-port-reset-4d9519570123
Best regards,
