On Mon, Jun 01, 2009 at 04:53:29PM +0900, Kenji Kaneshige wrote:
> @@ -571,14 +578,16 @@ int pci_hp_register(struct hotplug_slot
> return -EINVAL;
> }
>
> - mutex_lock(&pci_hp_mutex);
> + slot->ops->owner = owner;
> + slot->ops->mod_name = mod_name;
>
> + mutex_lock(&pci_hp_mutex);
Why not have the hotplug drivers fill in the ops->owner and ops->mod_name?
That would be the more common pattern within the kernel -- eg for
file_operations. There's only 9 places to change.
> Index: 20090529/drivers/pci/slot.c
> ===================================================================
> --- 20090529.orig/drivers/pci/slot.c
> +++ 20090529/drivers/pci/slot.c
> @@ -307,6 +307,50 @@ void pci_destroy_slot(struct pci_slot *s
> }
> EXPORT_SYMBOL_GPL(pci_destroy_slot);
>
> +#if defined(CONFIG_HOTPLUG_PCI) || defined(CONFIG_HOTPLUG_PCI_MODULE)
> +#include <linux/pci_hotplug.h>
> +/**
> + * pci_hp_create_link - create symbolic link to the hotplug driver module.
> + * @slot: struct pci_slot
> + *
> + * Helper function for pci_hotplug_core.c to create symbolic link to
> + * the hotplug driver module.
> + */
> +void pci_hp_create_module_link(struct pci_slot *pci_slot)
> +{
I don't understand why you want to put these functions in the slot
driver rather than in the PCI hotplug core. Then they'd be private to
the hotplug core.
> + struct hotplug_slot *slot = pci_slot->hotplug;
> + struct kobject *kobj = NULL;
> + int no_warn;
> +
> + if (!slot || !slot->ops)
> + return;
> + if (!slot->ops->owner)
> + kobj = kset_find_obj(module_kset, slot->ops->mod_name);
> +#ifdef CONFIG_MODULES
> + else
> + kobj = kobject_get(&slot->ops->owner->mkobj.kobj);
> +#endif /* CONFIG_MODULES */
Ew. Surely there's a better way ... even if it's putting the kobject
in the slot ops.
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
--
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
