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
