tree 43519bbb8ca93881605fdb01c44887c01e2219e5
parent b89bc283286b105e50aab9ab35992c0237ac77d8
author Rob Herring <robh@kernel.org> 1524229703 -0500
committer Rob Herring <robh@kernel.org> 1524574060 -0500

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>