1PCI bus bridges have standardized Device Tree bindings: 2 3PCI Bus Binding to: IEEE Std 1275-1994 4https://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf 5 6And for the interrupt mapping part: 7 8Open Firmware Recommended Practice: Interrupt Mapping 9https://www.devicetree.org/open-firmware/practice/imap/imap0_9d.pdf 10 11Additionally to the properties specified in the above standards a host bridge 12driver implementation may support the following properties: 13 14- linux,pci-domain: 15 If present this property assigns a fixed PCI domain number to a host bridge, 16 otherwise an unstable (across boots) unique number will be assigned. 17 It is required to either not set this property at all or set it for all 18 host bridges in the system, otherwise potentially conflicting domain numbers 19 may be assigned to root buses behind different host bridges. The domain 20 number for each host bridge in the system must be unique. 21- max-link-speed: 22 If present this property specifies PCI gen for link capability. Host 23 drivers could add this as a strategy to avoid unnecessary operation for 24 unsupported link speed, for instance, trying to do training for 25 unsupported link speed, etc. Must be '4' for gen4, '3' for gen3, '2' 26 for gen2, and '1' for gen1. Any other values are invalid. 27- reset-gpios: 28 If present this property specifies PERST# GPIO. Host drivers can parse the 29 GPIO and apply fundamental reset to endpoints. 30- supports-clkreq: 31 If present this property specifies that CLKREQ signal routing exists from 32 root port to downstream device and host bridge drivers can do programming 33 which depends on CLKREQ signal existence. For example, programming root port 34 not to advertise ASPM L1 Sub-States support if there is no CLKREQ signal. 35 36PCI-PCI Bridge properties 37------------------------- 38 39PCIe root ports and switch ports may be described explicitly in the device 40tree, as children of the host bridge node. Even though those devices are 41discoverable by probing, it might be necessary to describe properties that 42aren't provided by standard PCIe capabilities. 43 44Required properties: 45 46- reg: 47 Identifies the PCI-PCI bridge. As defined in the IEEE Std 1275-1994 48 document, it is a five-cell address encoded as (phys.hi phys.mid 49 phys.lo size.hi size.lo). phys.hi should contain the device's BDF as 50 0b00000000 bbbbbbbb dddddfff 00000000. The other cells should be zero. 51 52 The bus number is defined by firmware, through the standard bridge 53 configuration mechanism. If this port is a switch port, then firmware 54 allocates the bus number and writes it into the Secondary Bus Number 55 register of the bridge directly above this port. Otherwise, the bus 56 number of a root port is the first number in the bus-range property, 57 defaulting to zero. 58 59 If firmware leaves the ARI Forwarding Enable bit set in the bridge 60 above this port, then phys.hi contains the 8-bit function number as 61 0b00000000 bbbbbbbb ffffffff 00000000. Note that the PCIe specification 62 recommends that firmware only leaves ARI enabled when it knows that the 63 OS is ARI-aware. 64 65Optional properties: 66 67- external-facing: 68 When present, the port is external-facing. All bridges and endpoints 69 downstream of this port are external to the machine. The OS can, for 70 example, use this information to identify devices that cannot be 71 trusted with relaxed DMA protection, as users could easily attach 72 malicious devices to this port. 73 74Example: 75 76pcie@10000000 { 77 compatible = "pci-host-ecam-generic"; 78 ... 79 pcie@0008 { 80 /* Root port 00:01.0 is external-facing */ 81 reg = <0x00000800 0 0 0 0>; 82 external-facing; 83 }; 84}; 85