On Thu, Mar 22, 2018 at 09:35:04AM +0800, Arnd Bergman wrote: > On Thu, Mar 22, 2018 at 8:47 AM, David Gibson > <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Mar 21, 2018 at 02:55:33PM +0800, Arnd Bergman wrote: > >> On Wed, Mar 21, 2018 at 11:07 AM, David Gibson > >> <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > >> > On Tue, Mar 20, 2018 at 03:54:08AM -0500, Rob Herring wrote: > >> >> Having a 'bus-range' property for PCI bridges should not be required, > >> > > >> > Hmm. Shouldn't it? I thought it was a required property, but I'm > >> > having trouble interpreting the information in the PCI binding > >> > document to confirm that. > >> > >> Linux prints a message about the property not being there for the host > >> bridge node, but I believe that was meant to be informational rather > >> than a warning. > >> > >> The original PCI binding never had this property because it expected > >> the buses to be assigned by OF before we got into the kernel. > > > > Uh.. what? I'm guessing you mean that it *did* have the property > > because it expected the bus numbers to be assigned in firmware, rather > > than the other way around. > > > >> The problem we ran into with the dtc warning is when it warning about > >> child nodes of the pci host bridge on Marvell and Nvidia platforms. > >> These are device_type="pci" and correspond to a pcie root port, > >> but should get the bus numbers assigned dynamically. > > > > 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, which I'm pretty sure was based on the assumption that OF would fully enumerate the bus. > >> We could in theory have a check to enforce non-overlapping > >> bus ranges on pcie bridge nodes, with each one being within > >> the range of the parent node, but as this is such a rare case, > >> leaving out the warning seems easier. I just want to prevent > >> the warning from causing other people to actively add wrong > >> properties. > > > > Hrm. So, if firmware isn't enumerating the bus, the obviously it > > doesn't make sense to include bus-range properties. But is there a > > case where it doesn't make sense to include bus-range, but it *does* > > make sense to include the node at all? If the OS is going to > > enumerate the bus, it should be able to probe the bridges itself, yes? > > The specific case here is trying to model a PCI host controller > that is not a specific hardware block but rather split across multiple > PCIe root ports with their own MMIO register space combined with > a nonstandard parent node that has some more MMIO registers. > Both Marvell and NVIDIA ended up putting the child nodes into > DT as a way to configure each port more easily rather than having > a single combined node with lots of registers for all the ports, or > alternatively modeling each port as its own PCI domain and host > bridge, but requiring access to shared registers in some way. Ok. > AFAICT neither of the two driver actually looks at the bus-range > properties of the child nodes, and the ports just get assigned > the next free bus number while probing. It would be a useful > extension to allow setting a bus-range property for each port > to allow hotplugging pci bridges into the slots, but I don't see > a point until the drivers actually support hotplugging and interpret > the properties. Ok, sounds reasonable. Just trying to get a clearer picture of what's going on here. -- 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
