On Wed, Feb 19, 2014 at 2:58 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Tuesday 18 February 2014 17:28:14 Bjorn Helgaas wrote: >> On Sat, Feb 15, 2014 at 02:03:26PM +0100, Arnd Bergmann wrote: >> > On Friday 14 February 2014 22:00:47 Liviu Dudau wrote: >> > >> > Can anyone with more experience on the subject than me (Bjorn, >> > Russell, Jason, ...) think of a reason why we would not want to >> > just use a new domain for every host bridge we find? >> >> With ACPI on x86 and ia64, we currently use _SEG directly as the Linux >> PCI domain. Are you proposing that we make the Linux PCI domain >> independent of _SEG? > > I don't think we should change anything for ACPI. > The point is that we don't currently have the equivalent of _SEG > for DT probing. The best two options we have are: > > a) introduce a 'pci-segment' property with the same meaning as _SEG > on ACPI, and use that as the domain number > > b) don't introduce the segment concept on DT but just give each > host bridge its own domain. > > The second one seems a little easier to implement, and I don't > see what _SEG is used for other than to avoid having domains > when you don't need them. Is there more to it that I'm missing? Not really, but I do have a question related to OS management of host bridge bus number apertures. Currently, Linux never changes a host bridge's bus number range, but it's conceivable that we could in some hotplug scenario. ACPI does provide a mechanism to do so (_PRS, _SRS), and other host bridge drivers could also do this by programming CSRs to change the bus number range. The PCI domain is the logical place to manage allocation of the 00-ff range of bus numbers. 1) x86 platforms may have constraints because PCIBIOS and the 0xcf8 config access mechanism are unaware of segments. If a platform has to support legacy OSes that use those, it can't reuse bus numbers even in different segment groups. The platform might have to use multiple segments to allow multiple ECAM regions, but use _PRS/_SRS to prevent bus number overlaps to keep legacy config access working. Obviously this is only an issue if there are non-segment aware config access methods. 2) If two host bridges share an ECAM region, I think we're forced to put them in the same domain: if we put them in different domains, Linux might assign [bus 00-ff] to both bridges, and ECAM config accesses would only work for one of the bridges. This is quite common on x86 and is a potential issue for any architecture. Bjorn -- 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
