On Wed, Jul 16, 2025 at 05:22:58PM -0400, Frank Li wrote: > On Wed, Jul 16, 2025 at 03:42:07PM -0500, Bjorn Helgaas wrote: > > 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. > > I think it is controller implement problem, which route AER irq to > INTx or other irq line in SOC. Consider many users have similar > issues, can you add workaround or quirk for this type > implementation. I think the spec allows the AER interrupt to be routed to INTx, but only if the Root Port doesn't advertise MSI or MSI-X support or the OS decides not to enable MSI/MSI-X. Since there's no generic way to say "MSI/MSI-X works on this Root Port, but only for certain interrupts, not including AER," there's no way for Linux to figure out that it shouldn't enable MSI/MSI-X. *Somebody* can add some kind of quirk for this; not me because I don't have the hardware. It needs to be generic so the same solution works for all these devices. Bjorn
