On Sat, Mar 24, 2018 at 2:28 AM, David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Mar 22, 2018 at 09:35:04AM +0800, Arnd Bergman wrote: >> On Thu, Mar 22, 2018 at 8:47 AM, David Gibson >> > >> > Dynamically meaning what exactly? >> >> I meant bus numbers being assigned by the OS at boot time. >> >> When the firmware assigns the bus numbers, you can see >> the bus number in reg and assigned-address properties, and the >> bus-ranges property is not needed. > > Hm. Ok, then I'm a bit confused as to what the purpose of bus-ranges > ever was. It's not clear to me if it's supposed to be mandatory or > optional but it's certainly listed in the old OF PCI binding, I found it now, I'm sure I checked earlier but didn't spot it there the first time around. > which I'm pretty sure was based on the assumption that OF would fully > enumerate the bus. I'm aware of multiple existing use cases for bus-ranges: - Traditionally we 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 - In Open Firmware, I suspect this was just one more bit of redundant information, identical to what one finds in the secondary/subordinate bus numbers of a bridge device, same as other properties that duplicate information from config space. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html