On Fri, Apr 20, 2018 at 8:01 AM, David Gibson
<david@xxxxxxxxxxxxxxxxxxxxx> wrote:
> 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?
I was thinking of the kernel overall. This may have come from x86,
but that behavior was mimicked on ARM as well, and it looks like
most architectures still don't set CONFIG_PCI_DOMAINS (many
probably don't ever have more than one domain).
> 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.
That sounds plausible, though I hadn't heard of that before.
>> - 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.
This is the main reason we might actually decide keep a
requirement for bus-range properties in all nodes:
On architectures like ARM that almost always (re-)assign
all bus numbers at boot time, an empty slot gets just
one bus number. If you hot-plug a card with a pci-pci
bridge of some sort, only the top-level device can fit in,
since its children will not have a valid bus number.
Statically assigning a range of bus numbers to each
slot from the device tree could solve that problem, but
if we want to do that properly, we need two more things:
- Actually evaluate the property when assigning bus
numbers to non-root bridges
- Add some logic in dtc to require bus ranges of non-root
pci bridges to be non-overlapping with their sibling nodes,
as well as being subsets of their parents.
>> - 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.
Let's
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
