Handle PCI_RES_BUS on the Generic and ThunderX PCIe drivers.
This adds pci_alloc_domain() to allocate domain IDs when they are not
available from FDT/ACPI.
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
Hmm, pci_alloc_domain() seems dubious? Do you actually have multiple domains vs just having everything in a single domain? (All the x86 boxes are currently single-domain so just use a domain of 0, though ACPI supports multiple domains via _SEG and MCFG.) Presumably if there were multiple PCI domains / segments FDT would need to identify the domain the way ACPI does via _SEG?
| sys/arm64/cavium/thunder_pcie_pem.c | ||
|---|---|---|
| 792 ↗ | (On Diff #16565) | Can this ever attach to a device whose FDT entry might have a domain configured? |
| sys/dev/pci/pci_host_generic.c | ||
| 191 ↗ | (On Diff #16565) | Seems like this should be checking the "linux,pci-domain" property and only using pci_alloc_domain() if that isn't present? |
| sys/dev/pci/pci_subr.c | ||
| 299 ↗ | (On Diff #16565) | Maybe 'e.g. by ACPI or FDT'? To me using "on" here means that "ACPI or FDT" are examples of platforms where the firmware doesn't provide domain numbers, but that seems reverse to what you mean. Also, s/profided/provided/. Also, other comments in here use a double space after the end of a sentence. |
Comment Actions
Actually, 'sc->ecam' seems to be the PCI domain. It is what the drivers already return for the PCIB_IVAR_DOMAIN ivar, and looking at how it is constructed on arm64, it is effectively the upper N bits of the memory address for each PCI config access beyond the bus number (which is basically what a PCI domain means).