On Tue, Sep 9, 2014 at 10:41 AM, Jason Gunthorpe <jgunthorpe@xxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, Sep 09, 2014 at 08:26:19AM -0600, Bjorn Helgaas wrote: > >> So as long as the DT tells you the ECAM information for each host >> bridge, that should be sufficient. The domain number is then just a >> Linux convenience and is not tied to the platform as it is on ia64. > > I think this is right for DT systems - the domain is purely internal > to the kernel and userspace, it is used to locate the proper host > bridge driver instance, which contains the proper config accessor (and > register bases, etc). > > AFAIK the main reason to have a DT alias to learn the domain number is > to make it stable so things like udev/etc can reliably match on the > PCI location. For what purpose? > This is similar to i2c, etc that use the alias scheme, so IMHO > whatever they do to assign ID's to drivers should be copied for domain > numbers. IMO they should not. We really want to move away from aliases, not expand their use. They are used for serial because there was no good way to not break things like "console=ttyS0". I2C I think was more internal, but may have been for i2c-dev. What are we going to break if we don't have consistent domain numbering? If the domain goes into the DT, I'd rather see it as part of the PCI root node. But I'm not convinced it is needed. It doesn't really sound like we have any actual need to solve this for DT ATM. It's not clear to me if all buses should be domain 0 or a simple incrementing index for each bus in absence of any firmware set value. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
