On Thu, Sep 27, 2012 at 11:44 AM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >> >> I'm not sure if that is needed. > > That's a useless response. Do you want to elaborate on *why* you > think this is a bad idea? I did not say that is bad idea. it is just not needed to waste your time. > > I explained the reasons why I think it's a good idea above, but just > to expand on it, we currently have to create the struct pci_bus before > we can add _PRT information. But adding the _PRT info doesn't > actually depend on the struct pci_bus; it only requires the segment > number and the bus number. We have that information before we scan > the bus . > > I think it's useful to disentangle _PRT interface from the specifics > of PCI (in this case, the struct pci_bus). We're currently using the > struct pci_bus here just as a convenient way to pass around the > segment/bus number, but I don't think it's the appropriate abstraction > for that. > > Do you see a technical problem with it? Even if it's not *necessary* > in order to make host bridge hotplug work, I think it's worth doing to > make the code more understandable. > > Do you see a problem with adding the _PRT info before scanning the bus > or with removing it after deleting the bus? If the bus is not there, do not need that prt. So if you find the prt and add it to the list before, later if scanning fail etc failing path you will need to clean that prt in the list. > I'd like the bus scan > code to be able to scan/add/bind drivers all at once in the PCI core. > Today I think we have scan/add _PRT/device_add, where we have to do > this _PRT stuff in the middle, so we have to use two PCI interfaces > rather than one. looks like we handle _PRT in pci_host_bridge add/remove notification, just like Jiang's put that for pci device bus notifier. > > It's great if you see a way to remove acpi_pci_root_start() -- that > will be tremendous. that will need to more test. > I think the current PCI stop/remove split is a > similar issue, and I hope you can dream up a way to consolidate those, > too. that is SRIOV handling resign. I would suggest following way: use pf as parent for one new domain. and put all VFs on that domain. and the domain could have 256 buses for those VFs. and we have 16 bits domain number that could be used. current got too many patches in my quilt... hate to keep rebasing again. after pci root bus hotplug and for_each_res topic, will work on that SRIOV one. -Yinghai -- 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
