[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aTDpCpLUzxnAmvt6@google.com>
Date: Wed, 3 Dec 2025 17:51:06 -0800
From: Brian Norris <briannorris@...omium.org>
To: Qiang Yu <qiang.yu@....qualcomm.com>
Cc: Lorenzo Pieralisi <lpieralisi@...nel.org>,
Krzysztof WilczyĆski <kwilczynski@...nel.org>,
Manivannan Sadhasivam <mani@...nel.org>,
Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
Jingoo Han <jingoohan1@...il.com>, linux-pci@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH 3/5] PCI: dwc: Remove MSI/MSIX capability if iMSI-RX is
used as MSI controller
Hi,
On Sun, Nov 09, 2025 at 10:59:42PM -0800, Qiang Yu wrote:
> Some platforms may not support ITS (Interrupt Translation Service) and
> MBI (Message Based Interrupt), or there are not enough available empty SPI
> lines for MBI, in which case the msi-map and msi-parent property will not
> be provided in device tree node. For those cases, the DWC PCIe driver
> defaults to using the iMSI-RX module as MSI controller. However, due to
> DWC IP design, iMSI-RX cannot generate MSI interrupts for Root Ports even
> when MSI is properly configured and supported as iMSI-RX will only monitor
> and intercept incoming MSI TLPs from PCIe link, but the memory write
> generated by Root Port are internal system bus transactions instead of
> PCIe TLPs, so they are ignored.
>
> This leads to interrupts such as PME, AER from the Root Port not received
> on the host and the users have to resort to workarounds such as passing
> "pcie_pme=nomsi" cmdline parameter.
>
> To ensure reliable interrupt handling, remove MSI and MSI-X capabilities
> from Root Ports when using iMSI-RX as MSI controller, which is indicated
> by has_msi_ctrl == true. This forces a fallback to INTx interrupts,
But "has_msi_ctrl == false" does not necessarily mean it's using an
external MSI controller, does it? It could just mean that there's some
per-SoC customization needed via the .msi_init() hook.
In practice, that's only pci-keystone.c though, and it's not really
clear if that's some modified version of iMSI-RX, or something else
entirely. At any rate, I suppose it's best to only tweak the things we
know about -- unmodified DWC iMSI-RX support.
> eliminating the need for manual kernel command line workarounds.
>
> With this behavior:
> - Platforms with ITS/MBI support use ITS/MBI MSI for interrupts from all
> components.
> - Platforms without ITS/MBI support fall back to INTx for Root Ports and
> use iMSI-RX for other PCI devices.
>
> Signed-off-by: Qiang Yu <qiang.yu@....qualcomm.com>
> ---
> drivers/pci/controller/dwc/pcie-designware-host.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> index 20c9333bcb1c4812e2fd96047a49944574df1e6f..3724aa7f9b356bfba33a6515e2c62a3170aef1e9 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -1083,6 +1083,16 @@ int dw_pcie_setup_rc(struct dw_pcie_rp *pp)
>
> dw_pcie_dbi_ro_wr_dis(pci);
>
> + /*
> + * If iMSI-RX module is used as the MSI controller, remove MSI and
> + * MSI-X capabilities from PCIe Root Ports to ensure fallback to INTx
> + * interrupt handling.
> + */
Personally, I'd suggest including more of the "why?" in this comment, as
the "why?" is pretty perplexing to an uninitiated reader.
Maybe:
/*
* The iMSI-RX module does not support MSI or MSI-X generated by
* the root port. If iMSI-RX is used as the MSI controller,
* remove the MSI and MSI-X capabilities to fall back to INTx
* instead.
*/
> + if (pp->has_msi_ctrl) {
> + dw_pcie_remove_capability(pci, PCI_CAP_ID_MSI);
> + dw_pcie_remove_capability(pci, PCI_CAP_ID_MSIX);
Removing the capability structure is a neat idea. I had prototyped
solving this problem by adding a new PCI_MSI_FLAGS_* quirk, but that was
a lot more invasive. I like this idea instead!
This looks good to me, although maybe the comment could be updated. Feel
free to carry my:
Reviewed-by: Brian Norris <briannorris@...omium.org>
I'd also note, not all devices currently actually define their INTx
interrupts (such as ... my current test devices :( ), and so
pcie_init_service_irqs() / portdrv.c may fail entirely, since it can't
really provide any services if there are no IRQs for those services.
That does have at least one bad side effect: that the port won't be
configured for runtime PM and won't ever enter D3.
I wonder if we should allow pcie_port_device_register() to succeed even
if it ends up with an empty 'capabilities' / no services.
Brian
> + }
> +
> return 0;
> }
> EXPORT_SYMBOL_GPL(dw_pcie_setup_rc);
>
> --
> 2.34.1
>
>
Powered by blists - more mailing lists