summaryrefslogtreecommitdiff
path: root/lib
diff options
context:
space:
mode:
authorRob Herring <robh@kernel.org>2018-04-20 08:08:23 -0500
committerRob Herring <robh@kernel.org>2018-04-24 07:47:40 -0500
commit970f04c840f6004a1a956c1a836792a341d63eae (patch)
tree43519bbb8ca93881605fdb01c44887c01e2219e5 /lib
parentb89bc283286b105e50aab9ab35992c0237ac77d8 (diff)
dtc: checks: drop warning for missing PCI bridge bus-range
Cherry-picked from dtc upstream commit e1f139ea4900fd0324c646822b4061fec6e08321. Having a 'bus-range' property for PCI bridges should not be required, so remove the warning when missing. There was some confusion with the Linux kernel printing a message that no property is present and the OS assigned the bus number. This message was intended to be informational rather than a warning. When the firmware doesn't enumerate the PCI bus and leaves it up to the OS to do, then it is perfectly fine for the OS to assign bus numbers and bus-range is not necessary. There are a few cases where bus-range is needed or useful as Arnd Bergmann summarized: - Traditionally Linux avoided using multiple PCI domains, but instead configured separate PCI host bridges to have non-overlapping bus ranges so we can present them to user space as a single domain, and run the kernel without CONFIG_PCI_DOMAINS. Specifying the bus ranges this way would and give stable bus numbers across boots when the probe order is not fixed. - On certain ARM64 systems, we must only use the first 128 bus numbers based on the way the IOMMU identifies the device with truncated bus/dev/fn number. There are probably others like this, with various limitations. - To leave some room for hotplugged devices, each slot on a host bridge can in theory get a range of bus numbers that are available when assigning bus numbers at boot time Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Diffstat (limited to 'lib')
0 files changed, 0 insertions, 0 deletions