What I've managed to figure out so far is: - When adding a whole new host bridge, we create a hotplug slot after we have added & probed it. This is mostly to do unplug I suspect, though it's a bit weird. Now, the stuff you guys did would work as long as there is one (and only one) device below that PHB... without Alex latest patch. With it, I'm worried about creating a slot with the wrong devfn and then adding a device to it that don't match. - When adding a "slot" to a partition (either filled or empty), we do something similar: we add the P2P bridge and all devices below it to the linux tree and then create a pci hotplug "slot". However, I think that code path is only ever hit on POWER5 when adding slots, I believe that on P6, we only ever add PHBs (ie, each slot is a PHB), so that complicates my testing needs here. Again, here, the workaround you did will work if there is one and only one device below that P2P bridge. - In either case, if the PHB or slot added is empty, we don't know in advance the devfn of what can be plugged. [In fact, because "slots" are PHB's or P2P bridges, in -theory-, it would be possible to construct a machine that hot-adds several devices directly below such a slot, though I don't know if that exists in practice, I'll double check internally. (ie, not talking about a device with a P2P bridge on it, litteraly a machine that has more than one physical connector behind the "hotpluggable" PHB or P2P bridge. IE that would mean they have to be hotplugged all at once but still..] I'm not yet sure what the consequences vs. Alex infrastructure of this incapacity we have to know in advance what the devfn will be. Maybe we should just not create the slot if it's empty but I think that might prevent non-hypervisor controller hotplug on POWER4 where there is real old-style hotplug slots. There -might- be a trick we can use to figure out the child devfn's that I'm investigating. The PHB or P2P bridge that's plugged in contains an interrupt-map for interrupt routing. If they only put in there entries for the possible childs, which -seems- to be the case on the POWER6 machine I have at hand right now, I can use the devfn from that map. However, I've been told that some pSeries may have no support for LSIs at all on PCIe in which case those wouldn't even have an interrupt-map... This is a bit of a hack (well, it's a gross hack, allright), but it might work. I need to check whether this can be used reliably on all the various machine types we support. I don't know that for sure yet. I'll let you guys know what I can come up with. In the meantime, Alex, how bad is it to create slots with the wrong devfn in the first place ? I don't know much about the new PCI slot infrastructure so ... Cheers, Ben. -- 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
