On Wed, Jul 16, 2025 at 10:25:57AM -0700, Brian Norris wrote: > On Wed, Jul 16, 2025 at 09:35:38PM +0530, Manivannan Sadhasivam wrote: > > On Wed, Jul 16, 2025 at 08:20:38AM GMT, Brian Norris wrote: > > > On Wed, Jul 16, 2025 at 12:47:10PM +0530, Manivannan Sadhasivam wrote: > > > > On Wed, Jul 02, 2025 at 04:44:48PM GMT, Brian Norris wrote: > > > > > On Wed, Jul 02, 2025 at 07:09:42PM -0400, Frank Li wrote: > > > > > OTOH, I do also believe there are SoCs where DWC PCIe is > > > > > available, but there is no external MSI controller, and so > > > > > that same problem still may exist. I may even have such SoCs > > > > > available... > > > > > > > > Yes, pretty much all Qcom SoCs without GIC-v3 ITS suffer from > > > > this limitation. And the same should be true for other > > > > vendors also. > > > > > > > > Interestingly, the Qcom SoCs route the AER/PME via 'global' > > > > SPI interrupt, which is only handled by the controller driver. > > > > This is similar to the 'aer' SPI interrupt in layerscape > > > > platforms. > > > > > > Yeah, I have some SoCs like this as well. But I also believe > > > that I have INTx available, and that even when MSI doesn't work > > > for AER/PME, INTx might. > > > > > > Do Qcom SoCs route INTx? > > > > Yes, they do. But currently, we can only use it by booting with > > pcie_pme=nomsi cmdline parameter. Ugh. I think these controllers might be out of spec (or maybe we're not configuring MSI/MSI-X correctly for them). Per PCIe r7.0, sec 6.1.4.3: While enabled for MSI or MSI-X operation, a Function is prohibited from using INTx interrupts (if implemented) to request service (MSI, MSI-X, and INTx are mutually exclusive). If the controller advertises MSI or MSI-X, I think we will enable it and expect AER, PME, hotplug, etc. to use it. Bjorn
