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. Cool, so it sounds like you might be in a better spot than layerscape, based on the explanations I've seen from them. They seem to require multiplexing multiple platform-specific interrupts, which isn't as easy to pretend is a proper INTx line. > > > So I think there is an incentive in allowing the AER driver to work with vendor > > > specific IRQs. > > > > Yeah, I suppose even if my SoC (and Qcom, depending on the above answer) > > might work with INTx, it really does seem like an arbitrary decision > > about what SoC makers connected which DWC signals, so I suspect this is > > true. > > > > Maybe we should be able to extend the dmi quirk in portdrv.c to allow Root Ports > or host bridge to use INT-X instead of forcing them to use cmdline params. Yeah, it sounds like that would be sufficient for non-ITS Qualcomm PCIe, and also for my SoCs. It's also necessary (but maybe not sufficient) for Layerscape too. One complexity: this is not exclusively a "host bridge" quirk. It's also a quirk of the MSI provider. So for example, looking at arch/arm64/boot/dts/qcom/x1e80100.dtsi, you have 2 controllers without GIC ITS, and 2 with GIC ITS, all using the "same" type of bridge. IIUC, only the former 2 would need to fall back to INTx. Brian
