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. > > 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. - Mani -- மணிவண்ணன் சதாசிவம்
