Hi Bjorn,
I'm not so familiar with layerscape, but I'm familiar with parts of
this:
On Wed, Jul 02, 2025 at 05:38:41PM -0500, Bjorn Helgaas wrote:
> I see "aer" mentioned in layerscape DT 'interrupt-names':
>
> $ git grep "interrupt-names.*aer" Documentation/devicetree/bindings/pci/ arch
> Documentation/devicetree/bindings/pci/fsl,layerscape-pcie.yaml: interrupt-names = "aer";
> arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi: interrupt-names = "pme", "aer";
> arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi: interrupt-names = "pme", "aer";
> arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi: interrupt-names = "pme", "aer";
> ...
NB: in fsl-ls1012a.dtsi at least, the &pcie1 node has 'msi-parent =
<&msi>' that points at a 'fsl,ls1012a-msi'-compatible irqchip. I expect
that's how MSIs are getting resolved, and so that's likely how portdrv
gets its PME IRQ to enable AER among other things.
I think the other SoCs you point at above do something similar, or with
GIC ITS.
>
> But I don't know whether or how these are connected to the AER driver
> (drivers/pci/pcie/aer.c).
>
> Does the AER driver actually work on these platforms?
>
> Is there some magic that connects the 'interrupt-names'/'interrupts'
> DT properties to the pcie_device.irq that aer_probe() requests and
> hooks up with the aer_irq() handler?
I think you're right to notice the disconnect. I believe a typical DWC
implementation does not actually route the root port's PME/AER through
its MSI line, so many SoCs will have a dedicated platform IRQ for them
instead -- but I also don't know of any that actually hook those
platform IRQs up to the AER driver properly [1]. If they want AER, they
do something like commit ("9c4cd0aef259 arm64: dts: qcom: x1e80100:
enable GICv3 ITS for PCIe").
Brian
[1] Although I've seen some try to abuse interrupt-map to pretend that
their platform-AER interrupt is actually an INTx source... But that
breaks actually INTx support.
