[PATCH v10 07/10] OF: Introduce helper function for getting PCI domain_nr
From: Rob Herring <hidden>
Date: 2014-09-10 02:45:21
Also in:
linux-arch, linux-devicetree, linux-pci, lkml
From: Rob Herring <hidden>
Date: 2014-09-10 02:45:21
Also in:
linux-arch, linux-devicetree, linux-pci, lkml
On Tue, Sep 9, 2014 at 10:41 AM, Jason Gunthorpe [off-list ref] wrote:
On Tue, Sep 09, 2014 at 08:26:19AM -0600, Bjorn Helgaas wrote:quoted
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