On Mon, Apr 07, 2014 at 11:44:51PM +0100, Bjorn Helgaas wrote: > On Mon, Apr 7, 2014 at 4:07 AM, Liviu Dudau <Liviu.Dudau@xxxxxxx> wrote: > > On Mon, Apr 07, 2014 at 10:14:18AM +0100, Benjamin Herrenschmidt wrote: > >> On Mon, 2014-04-07 at 09:46 +0100, Liviu Dudau wrote: > >> > > >> > *My* strategy is to get rid of pci_domain_nr(). I don't see why we need > >> > to have arch specific way of providing the number, specially after looking > >> > at the existing implementations that return a value from a variable that > >> > is never touched or incremented. My guess is that pci_domain_nr() was > >> > created to work around the fact that there was no domain_nr maintainance in > >> > the generic code. > >> > >> Well, there was no generic host bridge structure. There is one now, it should > >> go there. > > > > Exactly! Hence my patch. After it gets accepted I will go through architectures > > and remove their version of pci_domain_nr(). > > Currently the arch has to supply pci_domain_nr() because that's the > only way for the generic code to learn the domain. After you add > pci_create_root_bus_in_domain(), the arch can supply the domain that > way, and we won't need the arch-specific pci_domain_nr(). Right? > That makes more sense to me; thanks for the explanation. Right. > > Let me try to explain my concern about the > pci_create_root_bus_in_domain() interface. We currently have these > interfaces: > > pci_scan_root_bus() > pci_scan_bus() > pci_scan_bus_parented() > pci_create_root_bus() > > pci_scan_root_bus() is a higher-level interface than > pci_create_root_bus(), so I'm trying to migrate toward it because it > lets us remove a little code from the arch, e.g., pci_scan_child_bus() > and pci_bus_add_devices(). > > I think we can only remove the arch-specific pci_domain_nr() if that > arch uses pci_create_root_bus_in_domain(). When we convert an arch > from using scan_bus interfaces to using > pci_create_root_bus_in_domain(), we will have to move the rest of the > scan_bus code (pci_scan_child_bus(), pci_bus_add_devices()) back into > the arch code. > > One alternative is to add an _in_domain() variant of each of these > interfaces, but that doesn't seem very convenient either. My idea of > passing in a structure would also require adding variants, so there's > not really an advantage there, but I am thinking of the next > unification effort, e.g., for NUMA node info. I don't really want to > have to change all the _in_domain() interfaces to also take yet > another parameter for the node number. OK, what about this: all the functions that you have mentioned take a void *sysdata parameter. Should we convert this opaque pointer into a specific structure that holds the domain_nr and (in future) the NUMA node info? Converting all the architectures is going to be a long winded job as everyone loved to add their own stuff in the structure pointed by sysdata, breaking that will lead to frustrations, but maybe the framework should take back ownership of it. Best regards, Liviu > > 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 > -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯ -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
