On Wed, Apr 27, 2011 at 1:51 PM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: > 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. Are they removing acpiphp support from all the systems in the field, too? Seriously, if we only do things that we can personally test on the machines we own, we're pretty limited in what we can do, and we'll end up with a hodge-podge of random fixes everywhere but no coherent overall plan. Sort of like what we have now, I guess :) >> 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. Is that true for all PCIe hotplug topologies? What about other hotplug drivers that might eventually use pci_assign_unassigned_bridge_resources()? If we *know* all the devices under the bridge, why don't we just remove their resources explicitly? That would protect us when this assumption changes. If we remove resources explicitly, things will start failing in a reasonable way if it turns out that there are unexpected child resources. If we blindly remove all the children, I think we have the potential for difficult-to-debug problems. 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
