> Between the root complex and whatever's plugged in? Yes.
> > so that is what the node represents. Its always been a bit confusing to me > > as its not 100% standardized by PCI sig. It's absolutely standard. The only case where you have "siblings" to that RC is when it's some kind of integrated chipset with non-PCI devices in it (still common in Intel world). Any real PCIe device -must- have a P2P above it with the PCIe capability & associated control registers. > Is it documented anywhere (e.g. in the chip manual)? Is it common (even > if 100% standardized), or a Freescale-ism? PCIe spec. > Is there an actual PCIe-to-PCIe bridge that shows up in the root > complex's config space Yes. > (not talking about the host bridge PCI device > that has always been there on FSL PCI controllers, which we didn't > represent in the device tree on non-express PCI)? Why does this bridge > need to be represented in the device tree (assuming no ISA devices need > to be represented), when other PCI devices (including bridges) don't? You don't have to, but we sometimes do it so we can put the interrupt-map in the right place. But again, since on PCIe the device underneath should always have dev 0 for non-SRIOV stuff, the swizzling shall be NOP and so having the interrupt-map all the way at the top might work. However I'm not sure if that will work with PFs and ARI where the dev is non-0. > > Maybe Ben's got some comments to add here from a generic PCIe point of view. > > > >>>> Do we really need the error interrupt specified twice? > >>> > >>> I put it twice because it has multiple purposes, one has to do with > >>> interrupts defined by the PCI spec vs ones defined via FSL controller. > >> > >> There are PCI-defined error conditions that cause a host controller > >> interrupt. What does this have to do with the bridge node? > > > > Think of the "error" IRQ as shared between to classes of interrupts. One > > set are controller errors defined by FSL, the other are errors defined by > > PCI sig / bus point of view. > > > > I'd expect controller errors to be handled by something like EDAC would > > bind at "fsl,qoriq-pcie-v2.2" level node. The PCI bus code would looks at > > the virtual bridge down. > > This shouldn't be about where a specific piece of Linux code looks. > > I don't see why the split of PCI-defined errors versus FSL-defined > errors maps to bridge node versus controller node. What if we didn't > have the bridge? We'd still have PCI-defined errors, right? The linux generic PCIe port driver looks for the interrupt of the bridge for standardized PCIe AER interrupts. Cheers, Ben. > -Scott > > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
