* Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>:
>
> [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.
[...]
> 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 ...
So the fact that slots are actually bridges seems like it might
actually work out ok in the new infrastructure.
We're using the combination of pci_bus and devfn to keep track of
slots we've created. If each pseries slot is its own pci_bus,
then faking in a 0 devfn for unpopulated slots at the least won't
be harmful.
Once a device is plugged into the slot, then the slot's pci_bus
would have two entries, the fake 0 devfn and the real devfn of
the actual device.
If the device is hot-unplugged, you'd be left with the slot and
the fake devfn. If the slot is removed from the lpar by the
hypervisor, that's when we'd release that fake device.
Hm?
This snippet below from my 3/4 patch is the function where we do
this pci_bus / devfn bookkeeping. It's called by pci_hp_register,
and it's also called by the ACPI slot detection driver in my 4/4
patch.
Thanks.
/ac
+struct pci_slot *pci_create_slot(struct pci_bus *parent, int slot_nr,
+ const char *name)
+{
+ struct pci_slot *slot;
+ int err;
+
+ down_write(&pci_bus_sem);
+
+ /* If we've already created this slot, bump refcount and return. */
+ list_for_each_entry(slot, &parent->slots, list) {
+ if (slot->number == slot_nr) {
+ kobject_get(&slot->kobj);
+ pr_debug("%s: bumped refcount to %d on %x:%d\n",
+ __func__,
+ atomic_read(&slot->kobj.kref.refcount),
+ parent->number, slot_nr);
+ goto out;
+ }
+ }
+
+ slot = kzalloc(sizeof(*slot), GFP_KERNEL);
+ if (!slot) {
+ slot = ERR_PTR(-ENOMEM);
+ goto out;
+ }
+
+ slot->bus = parent;
+ slot->number = slot_nr;
+
+ slot->kobj.kset = pci_slots_kset;
+ err = kobject_init_and_add(&slot->kobj, &pci_slot_ktype, NULL,
+ "%s", name);
+ if (err) {
+ printk(KERN_ERR "Unable to register kobject %s\n", name);
+ goto err;
+ }
+
+ INIT_LIST_HEAD(&slot->list);
+ list_add(&slot->list, &parent->slots);
+
+ pr_debug("%s: created pci_slot on %x:%d\n",
+ __func__, parent->number, slot_nr);
+
+ out:
+ up_write(&pci_bus_sem);
+ return slot;
+ err:
+ kfree(slot);
+ slot = ERR_PTR(err);
+ goto out;
+}
+EXPORT_SYMBOL_GPL(pci_create_slot);
--
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
