Thread (48 messages) 48 messages, 11 authors, 2014-09-12

[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

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help