kinda...

at least for the intel iommu

it caches the iommu_t responsible for a device in the device's dev_info_t, but the first time, it does traverse up the tree to find the 'domain' the device is in

which is usually it's own, but then also traverses the tree up to find the iommu_t responsible for the device the first time (then caches it)

apparently, I had the ddi and the rootnex bit swapped in my mind.

I mean the way rootnex_dma* call into iommulib* in that way they do

one of the other things I need to put up is we do traverse too far looking for the top most device in a domain

and blow right by the root complex

and go all the way to the root nexus

though right now my fix looks at the device binding name and terminates the walk if it's 'pciex_root_complex'

but I don't know if there's a better way to handle that

jbk: some sort of attribute on the device indicating that it's a root complex?

that's waht I was wondering, but the only thing I found was create_pcie_root_bus() (in the somewhat confusingly named pcie_nvidia.c)

which just sets device_type and compatible

jbk: that's for an nvidia PCIe chipset, IIRC

( en.wikipedia.org/wiki/Comparison_of_Nvidia_nForce_chipsets )

it appears to get called from pci_boot.c

yeah, it gets a funny name on x86

npe was originally named as if for nForce PCI-e

but is now the "nexus for..." PCI-e

ahh..

the "nvidia" in the name is vestigial

pcie_get_rc_dip is probably the best way I know to find an RC in your ancestry to terminate a search

(it checks the bus private data)

:o

hrm... looks like redmine is having issues again...