From: Shawn Lin <shawn.lin@rock-chips.com>
To: Koichiro Den <den@valinux.co.jp>
Cc: shawn.lin@rock-chips.com,
"Marek Vasut" <marek.vasut+renesas@mailbox.org>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"Yoshihiro Shimoda" <yoshihiro.shimoda.uh@renesas.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Magnus Damm" <magnus.damm@gmail.com>,
"Jingoo Han" <jingoohan1@gmail.com>,
"Philipp Zabel" <p.zabel@pengutronix.de>,
"Frank Li" <Frank.Li@nxp.com>,
"Niklas Cassel" <cassel@kernel.org>,
"Wilfred Mallawa" <wilfred.mallawa@wdc.com>,
"Serge Semin" <fancer.lancer@gmail.com>,
linux-pci@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 10/17] PCI: dwc: Free the MSI domain after the host .deinit() callback
Date: Tue, 20 Oct 2026 15:00:36 +0800 [thread overview]
Message-ID: <55944278-6103-48e9-a664-c423a3a1ac7d@rock-chips.com> (raw)
In-Reply-To: <ghdrvrjbozm32y3o5m5vw6tl4l2tcep4ok4i6vtcvgbsbnb662@7katihdy32nl>
在 2026/10/20 星期二 14:41, Koichiro Den 写道:
> On Tue, Oct 20, 2026 at 11:54:18AM +0800, Shawn Lin wrote:
>> Hi Koichiro
>>
>> 在 2026/10/20 星期二 11:10, Koichiro Den 写道:
>>> dw_pcie_host_deinit() frees the iMSI-RX domain before calling the host
>>> .deinit() callback. For a core-owned parent interrupt,
>>> dw_pcie_free_msi() removes the chained handler right before the domain.
>>> A glue driver that owns the parent interrupt and demultiplexes the MSIs
>>> itself through dw_handle_msi_irq() can only stop its handler in
>>> .deinit(), after the domain is gone, so a late interrupt can still
>>> dispatch into the freed domain.
>>>
>>
>> I think you need a rebase anyway since there are two patches touching
>> MSI irq naming stuff in pci-tree's next branch and will probably
>> show up in tommorow's linux-next.
>
> Hi Shawn, thanks for the heads-up! And thanks for the review.
>
>>
>> ...
>>
>>> +static void dw_pcie_free_msi_domain(struct dw_pcie_rp *pp)
>>> +{
>>> irq_domain_remove(pp->irq_domain);
>>> + pp->irq_domain = NULL;
>>> +}
>>> +
>>> +void dw_pcie_free_msi(struct dw_pcie_rp *pp)
>>> +{
>>> + dw_pcie_remove_msi_handlers(pp);
>>> + dw_pcie_free_msi_domain(pp);
>>> }
>>> EXPORT_SYMBOL_GPL(dw_pcie_free_msi);
>>
>>
>> dw_pcie_free_msi() now calls freeing irq_domain unconditionally:
>>
>> The problem is that pcie-qcom.c uses the ECAM init path, which does not
>> go through dw_pcie_host_init(), and registers its own devres action,
>> see:
>> drivers/pci/controller/dwc/pcie-qcom.c:2034
>> return devm_add_action_or_reset(dev, qcom_pci_free_msi, pp);
>>
>> drivers/pci/controller/dwc/pcie-qcom.c:1995
>> static void qcom_pci_free_msi(void *ptr)
>> {
>> struct dw_pcie_rp *pp = (struct dw_pcie_rp *)ptr;
>>
>> if (pp && pp->use_imsi_rx)
>> dw_pcie_free_msi(pp);
>> }
>>
>> This leads to the following sequence:
>>
>> 1. dw_pcie_host_init() succeeds and pp->irq_domain is created;
>> 2. the driver is removed or probe fails, dw_pcie_host_deinit() calls
>> dw_pcie_free_msi_domain() and sets pp->irq_domain to NULL;
>> 3. the devres action qcom_pci_free_msi() still holds the same pp and
>> calls dw_pcie_free_msi(), which enters dw_pcie_free_msi_domain()
>> again;
>
> I'm a bit confused. Steps 1 and 2 here seem to describe the regular DWC path,
> but the devres action in step 3 looks like it's only registered in the
> firmware-managed ECAM path. I don't see where that path would call
> dw_pcie_host_deinit(). Am I missing something?
>
My apologies for any confusion my earlier response may have caused. I
brought up qcom merely as an example of a driver managing the MSI IRQ
lifecycle with its own devres action, with a remove path that can go
through dw_pcie_host_deinit(). For such combinations the safe check I
suggested would matter, I intended this as a defensive improvement, not
necessarily implying a bug exists now.
> Best regards,
> Koichiro Den
>
>> 4. irq_domain_remove(NULL) dereferences a NULL pointer and the kernel
>> crashes.
>>
>>
>> So I suggest you to add a safe check if (!pp->irq_domain) before doing
>> that.
>>
>>
>>> @@ -633,7 +643,7 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp)
>>> ret = of_pci_get_equalization_presets(dev, &pp->presets, pci->num_lanes);
>>> if (ret)
>>> - goto err_free_msi;
>>> + goto err_deinit_host;
>>> /*
>>> * Allocate the resource for MSG TLP before programming the iATU
>>> @@ -649,7 +659,7 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp)
>>> ret = dw_pcie_edma_detect(pci);
>>> if (ret)
>>> - goto err_free_msi;
>>> + goto err_deinit_host;
>>> ret = dw_pcie_setup_rc(pp);
>>> if (ret)
>>> @@ -686,14 +696,16 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp)
>>> err_remove_edma:
>>> dw_pcie_edma_remove(pci);
>>> -err_free_msi:
>>> - if (pp->use_imsi_rx)
>>> - dw_pcie_free_msi(pp);
>>> -
>>> err_deinit_host:
>>> + if (pp->use_imsi_rx && pp->irq_domain)
>>> + dw_pcie_remove_msi_handlers(pp);
>>> +
>>> if (pp->ops->deinit)
>>> pp->ops->deinit(pp);
>>> + if (pp->use_imsi_rx && pp->irq_domain)
>>> + dw_pcie_free_msi_domain(pp);
>>> +
>>> err_free_ecam:
>>> if (pp->cfg)
>>> pci_ecam_free(pp->cfg);
>>> @@ -718,11 +730,14 @@ void dw_pcie_host_deinit(struct dw_pcie_rp *pp)
>>> dw_pcie_edma_remove(pci);
>>> if (pp->use_imsi_rx)
>>> - dw_pcie_free_msi(pp);
>>> + dw_pcie_remove_msi_handlers(pp);
>>> if (pp->ops->deinit)
>>> pp->ops->deinit(pp);
>>> + if (pp->use_imsi_rx)
>>> + dw_pcie_free_msi_domain(pp);
>>> +
>>> if (pp->cfg)
>>> pci_ecam_free(pp->cfg);
>>> }
>>
>
next prev parent reply other threads:[~2026-10-20 7:00 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 3:10 [PATCH v5 00/17] PCI: rcar-gen4: Recover from link down and route Root Port interrupts Koichiro Den
2026-10-20 3:10 ` [PATCH v5 01/17] PCI: dwc: Add Renesas to the RAS DES VSEC list Koichiro Den
2026-10-20 3:10 ` [PATCH v5 02/17] PCI: dwc: Factor out the PORT_LINK_DEBUG1 link-up check Koichiro Den
2026-10-20 3:10 ` [PATCH v5 03/17] PCI: rcar-gen4: Check live link status in link_up() Koichiro Den
2026-10-20 3:10 ` [PATCH v5 04/17] dt-bindings: PCI: rcar-gen4: Add optional "aer" interrupt for R-Car Gen4 SoCs Koichiro Den
2026-10-20 12:45 ` Marek Vasut
2026-10-20 3:10 ` [PATCH v5 05/17] PCI: dwc: Export dw_handle_msi_irq() Koichiro Den
2026-10-20 3:10 ` [PATCH v5 06/17] PCI: rcar-gen4: Move deinitialization helpers before SoC initialization Koichiro Den
2026-10-20 3:10 ` [PATCH v5 07/17] PCI: rcar-gen4: Assert resets when Gen5 SoC PHY initialization fails Koichiro Den
2026-10-20 3:10 ` [PATCH v5 08/17] PCI: rcar-gen4: Separate hardware setup from resource acquisition Koichiro Den
2026-10-20 3:10 ` [PATCH v5 09/17] PCI: rcar-gen4: Add Root Port reset support Koichiro Den
2026-10-20 3:10 ` [PATCH v5 10/17] PCI: dwc: Free the MSI domain after the host .deinit() callback Koichiro Den
2026-10-20 3:54 ` Shawn Lin
2026-10-20 6:41 ` Koichiro Den
2026-10-20 7:00 ` Shawn Lin [this message]
2026-10-20 7:21 ` Koichiro Den
2026-10-20 11:47 ` Geert Uytterhoeven
2026-10-20 13:45 ` Koichiro Den
2026-10-20 3:10 ` [PATCH v5 11/17] PCI: rcar-gen4: Take over the iMSI-RX interrupt Koichiro Den
2026-10-20 3:10 ` [PATCH v5 12/17] PCI: rcar-gen4: Recover the Root Port on link down Koichiro Den
2026-10-20 3:10 ` [PATCH v5 13/17] PCI: rcar-gen4: Route Root Port AER to a virtual Root Port IRQ Koichiro Den
2026-10-21 0:19 ` Marek Vasut
2026-10-20 3:10 ` [PATCH v5 14/17] PCI: rcar-gen4: Route Root Port PME and bandwidth notifications Koichiro Den
2026-10-20 3:10 ` [PATCH v5 15/17] arm64: dts: renesas: r8a779f0: Describe the PCIe AER interrupts Koichiro Den
2026-10-20 3:10 ` [PATCH v5 16/17] arm64: dts: renesas: r8a779g0: " Koichiro Den
2026-10-20 3:10 ` [PATCH v5 17/17] arm64: dts: renesas: r8a779h0: Describe the PCIe AER interrupt Koichiro Den
2026-10-20 8:03 ` [PATCH v5 00/17] PCI: rcar-gen4: Recover from link down and route Root Port interrupts Geert Uytterhoeven
2026-10-20 8:45 ` Koichiro Den
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=55944278-6103-48e9-a664-c423a3a1ac7d@rock-chips.com \
--to=shawn.lin@rock-chips.com \
--cc=Frank.Li@nxp.com \
--cc=bhelgaas@google.com \
--cc=cassel@kernel.org \
--cc=conor+dt@kernel.org \
--cc=den@valinux.co.jp \
--cc=devicetree@vger.kernel.org \
--cc=fancer.lancer@gmail.com \
--cc=geert+renesas@glider.be \
--cc=jingoohan1@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=magnus.damm@gmail.com \
--cc=mani@kernel.org \
--cc=marek.vasut+renesas@mailbox.org \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=wilfred.mallawa@wdc.com \
--cc=yoshihiro.shimoda.uh@renesas.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
all inboxes | Powered by JetHome®