On 04/27/2011 12:44 PM, Bjorn Helgaas wrote: > On Wed, Apr 27, 2011 at 11:11 AM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: >>> now before we build more things on top of it. >> >> pciehp hotplug path is calling pci_assign_unassigned_bridge_resources() instead. >> it only update the bridge itself and will not go up. > > 1) Why does only pciehp call pci_assign_unassigned_bridge_resources()? > Is there something special about pciehp that means it needs that > call, while none of the other hotplug drivers do? I would have > thought they should all have similar _configure_device() functions. only can test pciehp here. also FW is removing support for acpiphp. > We have a whole list of functions including > > pciehp_configure_device > cpci_configure_slot > cpqhp_configure_device > shpchp_configure_device > ibm_configure_device > cb_alloc > sgi_hotplug enable_slot > acpiphp enable_device > > that are disturbingly similar, yet different in the particulars. I > suspect that there should be a lot of unification here. > > 2) As you say, pciehp_configure_device() calls > pci_assign_unassigned_bridge_resources(), which ultimately calls > release_child_resources(). But you didn't answer my question: how do > we know it's safe to release child resources under the bridge? Do we > know somehow that there are no drivers bound to devices below the > bridge? Are we assuming that there's only one device (the newly > hot-added one) below the bridge? Is that true for all potential > callers of pci_assign_unassigned_bridge_resources()? the devices or bridges under that pci bridge are not binding to drivers yet when hot add happen. 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
