diff options
author | Rob Herring <robh@kernel.org> | 2018-04-20 08:08:23 -0500 |
---|---|---|
committer | Rob Herring <robh@kernel.org> | 2018-04-24 07:47:40 -0500 |
commit | 970f04c840f6004a1a956c1a836792a341d63eae (patch) | |
tree | 43519bbb8ca93881605fdb01c44887c01e2219e5 /lib | |
parent | b89bc283286b105e50aab9ab35992c0237ac77d8 (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