On Mon, Mar 26, 2018 at 02:32:48PM +0200, Arnd Bergman 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. Sorry I lost track of this one. > > 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. Hmm. Who is "we"? I thought it was only x86 that tried to avoid thinking about PCI domains? On ppc - or at least CHRP/RPA/PAPR platforms - I thought one reason for bus-ranges was because pHyp wanted to pass through subsections of the PCI tree without virtualizing the bus numbers. Meaning the LPAR / guest wasn't able to re-enumerate them. > - 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. Ok. > - 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 I can't quite make sense of that. > - 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. Yeah, maybe. Well, I guess I'm more-or-less concvinced - unfortunately I lost track of the original patch. Can you please resend - preferably with a bit of expanded rationale based on the above discussion in the commit message. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
