On Mon, Mar 26, 2018 at 7:32 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > 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. David, I'm waiting for this to be applied before I cherry-pick it to the kernel's copy to fix the warnings. Any other comments on this? Rob -- 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
