From: Niklas Cassel <cassel@kernel.org>
To: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Manivannan Sadhasivam <mani@kernel.org>,
linux-rockchip@lists.infradead.org, linux-pci@vger.kernel.org,
Peter Geis <pgwipeout@gmail.com>
Subject: Re: [PATCH 2/2] PCI: dw-rockchip: Do not recreate the INTx irq domain on root port reset
Date: Thu, 3 Sep 2026 10:37:57 +0200 [thread overview]
Message-ID: <apkx5X83hrHIPOZN@ryzen> (raw)
In-Reply-To: <1788403477-71491-3-git-send-email-shawn.lin@rock-chips.com>
On Thu, Sep 03, 2026 at 10:44:37AM +0800, Shawn Lin wrote:
> .reset_root_port() re-runs the host ops .init() callback to reprogram
> the Root Complex after the controller reset. However, .init() also
> creates a new INTx irq domain on every root port reset, so that:
>
> - the previous irq domain is leaked, as it is never removed, and two
> irq domains end up registered for the same fwnode;
>
> - the INTx virqs of the downstream PCI devices were allocated in the
> previous irq domain and are never re-mapped, while the chained
> handler now looks up virqs in the new, empty domain. Hence, after a
> link down recovery, INTx interrupts are silently lost.
>
> Split the (re)programming of the Root Complex registers out of .init()
> into rockchip_pcie_host_hw_init() and call that from .reset_root_port()
> instead. The INTx irq domain and the chained handler are now only set up
> once, at probe time, which keeps the already mapped virqs valid across
> root port resets.
>
> Fixes: b376b3ff9cb0 ("PCI: dw-rockchip: Implement .reset_root_port() and use for link down")
> Cc: Niklas Cassel <cassel@kernel.org>
> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
>
> ---
If I compare to pcie-qcom.c, the difference is that they do
e.g.:
irq = platform_get_irq_byname_optional(pdev, "global");
after calling dw_pcie_host_init() in qcom_pcie_probe().
I guess pcie-dw-rockchip.c could do the same:
Call of_irq_get_byname() and rockchip_pcie_init_irq_domain() in
rockchip_pcie_configure_rc(), after calling dw_pcie_host_init().
That way, you don't need to introduce another rockchip_pcie_host_hw_init().
pci->pp.ops->init() is called by both dw_pcie_host_init() and
dw_pcie_resume_noirq(). So calling of_irq_get_byname() in .init()
does seem slightly wrong, as we would get the irq on each resume.
Perhaps pcie-dw-rockchip.c does not have support for resume, so it
does not matter right now, but still seems a bit weird to call
of_irq_get_byname() in init().
I did not look if rockchip_pcie_init_irq_domain() should be called
on each resume, but I since we don't tear down the irq_domain in
pci->pp.ops->deinit(), in fact we don't even have a ->deinit(),
so calling rockchip_pcie_init_irq_domain() in ->init() does seem
wrong as well.
So my vote is to move both to rockchip_pcie_configure_rc(), after
calling dw_pcie_host_init().
Kind regards,
Niklas
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2026-09-03 8:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 2:44 [PATCH 0/2] Two small INTx fixes for Rockchip's dwc based PCIe controller driver Shawn Lin
2026-09-03 2:44 ` [PATCH 1/2] PCI: dw-rockchip: Bail out if the INTx irq domain creation fails Shawn Lin
2026-09-03 2:44 ` [PATCH 2/2] PCI: dw-rockchip: Do not recreate the INTx irq domain on root port reset Shawn Lin
2026-09-03 8:37 ` Niklas Cassel [this message]
2026-09-03 10:02 ` Shawn Lin
2026-09-03 8:20 ` [PATCH 0/2] Two small INTx fixes for Rockchip's dwc based PCIe controller driver Niklas Cassel
2026-09-03 8:26 ` Shawn Lin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=apkx5X83hrHIPOZN@ryzen \
--to=cassel@kernel.org \
--cc=bhelgaas@google.com \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mani@kernel.org \
--cc=pgwipeout@gmail.com \
--cc=shawn.lin@rock-chips.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox