Re: Does dwc/pci-layerscape.c support AER?

[Brian Norris <briannorris@chromium.org>]

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