[2/3] PCI hotplug: create symlink to hotplug driver module

Commit Message

Kenji Kaneshige June 15, 2009, 2:23 a.m. UTC

Create symbolic link to hotplug driver module in the PCI slot
directory (/sys/bus/pci/slots/<SLOT#>). In the past, we need to load
hotplug drivers one by one to identify the hotplug driver that handles
the slot, and it was very inconvenient especially for trouble shooting.
With this change, we can easily identify the hotplug driver.

Signed-off-by: Taku Izumi <[e-mail]>
Signed-off-by: Kenji Kaneshige <[e-mail]>

---
 Documentation/ABI/testing/sysfs-bus-pci |    7 +++++
 drivers/pci/hotplug/pci_hotplug_core.c  |   23 +++++++++++++-----
 drivers/pci/slot.c                      |   39 ++++++++++++++++++++++++++++++++
 include/linux/pci.h                     |    5 ++++
 include/linux/pci_hotplug.h             |   15 ++++++++++--
 5 files changed, 80 insertions(+), 9 deletions(-)



--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Alexander Chiang June 15, 2009, 5:52 p.m. UTC | #1

* Kenji Kaneshige <[e-mail]>:
> Create symbolic link to hotplug driver module in the PCI slot
> directory (/sys/bus/pci/slots/<SLOT#>). In the past, we need to load
> hotplug drivers one by one to identify the hotplug driver that handles
> the slot, and it was very inconvenient especially for trouble shooting.
> With this change, we can easily identify the hotplug driver.
 
I think this implementation is much nicer than the previous one.

One comment below regarding the symlink name.

> Index: 20090612/drivers/pci/slot.c
> ===================================================================
> --- 20090612.orig/drivers/pci/slot.c
> +++ 20090612/drivers/pci/slot.c
> @@ -307,6 +307,45 @@ 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)
> +{
> +	struct hotplug_slot *slot = pci_slot->hotplug;
> +	struct kobject *kobj = NULL;
> +	int no_warn;
> +
> +	if (!slot || !slot->ops)
> +		return;
> +	kobj = kset_find_obj(module_kset, slot->ops->mod_name);
> +	if (!kobj)
> +		return;
> +	no_warn = sysfs_create_link(&pci_slot->kobj, kobj, "module");

I would prefer to call this link "hotplug_module" or "hp_module".
The reason is, if we ever decide to create another link for that
slot's low level device driver, we won't be limited by something
that already called "module".

Thanks.

/ac

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Greg KH June 15, 2009, 7:02 p.m. UTC | #2

On Mon, Jun 15, 2009 at 11:52:31AM -0600, Alex Chiang wrote:
> * Kenji Kaneshige <[e-mail]>:
> > Create symbolic link to hotplug driver module in the PCI slot
> > directory (/sys/bus/pci/slots/<SLOT#>). In the past, we need to load
> > hotplug drivers one by one to identify the hotplug driver that handles
> > the slot, and it was very inconvenient especially for trouble shooting.
> > With this change, we can easily identify the hotplug driver.
>  
> I think this implementation is much nicer than the previous one.
> 
> One comment below regarding the symlink name.
> 
> > Index: 20090612/drivers/pci/slot.c
> > ===================================================================
> > --- 20090612.orig/drivers/pci/slot.c
> > +++ 20090612/drivers/pci/slot.c
> > @@ -307,6 +307,45 @@ 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)
> > +{
> > +	struct hotplug_slot *slot = pci_slot->hotplug;
> > +	struct kobject *kobj = NULL;
> > +	int no_warn;
> > +
> > +	if (!slot || !slot->ops)
> > +		return;
> > +	kobj = kset_find_obj(module_kset, slot->ops->mod_name);
> > +	if (!kobj)
> > +		return;
> > +	no_warn = sysfs_create_link(&pci_slot->kobj, kobj, "module");
> 
> I would prefer to call this link "hotplug_module" or "hp_module".
> The reason is, if we ever decide to create another link for that
> slot's low level device driver, we won't be limited by something
> that already called "module".

Note that "module" is already used in sysfs, so as long as you are
pointing to the same thing that those other symlinks are, you should be
fine.  You are pointing to /sys/module/NAME, here, right?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Alexander Chiang June 15, 2009, 7:20 p.m. UTC | #3

* Greg KH <[e-mail]>:
> On Mon, Jun 15, 2009 at 11:52:31AM -0600, Alex Chiang wrote:
> > * Kenji Kaneshige <[e-mail]>:
> > > Create symbolic link to hotplug driver module in the PCI slot
> > > directory (/sys/bus/pci/slots/<SLOT#>). In the past, we need to load
> > > hotplug drivers one by one to identify the hotplug driver that handles
> > > the slot, and it was very inconvenient especially for trouble shooting.
> > > With this change, we can easily identify the hotplug driver.
> >  
> > I think this implementation is much nicer than the previous one.
> > 
> > One comment below regarding the symlink name.
> > 
> > > Index: 20090612/drivers/pci/slot.c
> > > ===================================================================
> > > --- 20090612.orig/drivers/pci/slot.c
> > > +++ 20090612/drivers/pci/slot.c
> > > @@ -307,6 +307,45 @@ 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)
> > > +{
> > > +	struct hotplug_slot *slot = pci_slot->hotplug;
> > > +	struct kobject *kobj = NULL;
> > > +	int no_warn;
> > > +
> > > +	if (!slot || !slot->ops)
> > > +		return;
> > > +	kobj = kset_find_obj(module_kset, slot->ops->mod_name);
> > > +	if (!kobj)
> > > +		return;
> > > +	no_warn = sysfs_create_link(&pci_slot->kobj, kobj, "module");
> > 
> > I would prefer to call this link "hotplug_module" or "hp_module".
> > The reason is, if we ever decide to create another link for that
> > slot's low level device driver, we won't be limited by something
> > that already called "module".
> 
> Note that "module" is already used in sysfs, so as long as you are
> pointing to the same thing that those other symlinks are, you should be
> fine.  You are pointing to /sys/module/NAME, here, right?

Looks like the common use of "module" is:

	/sys/bus/$bus/drivers/$driver/module -> /sys/module/NAME

What I was reacting to is that this patch proposes:

	/sys/bus/pci/slots/$slot/module -> /sys/module/NAME

This scheme is fine as long as only PCI hotplug modules create
those $slot entries.

But it is limiting, if in the future, we teach the PCI core to
create $slot entries when a low level device driver, say tg3 or
whatever, is loaded.

In that scenario, it would be more logical if module pointed at
the LLDD's module, not whatever PCI hotplug module happens to
claim that slot

Since we're talking about an ABI agreement with userspace, I
think "hotplug_module" is better for future flexibility.

Thanks.

/ac

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Matthew Wilcox June 15, 2009, 7:36 p.m. UTC | #4

On Mon, Jun 15, 2009 at 01:20:36PM -0600, Alex Chiang wrote:
> > Note that "module" is already used in sysfs, so as long as you are
> > pointing to the same thing that those other symlinks are, you should be
> > fine.  You are pointing to /sys/module/NAME, here, right?
> 
> Looks like the common use of "module" is:
> 
> 	/sys/bus/$bus/drivers/$driver/module -> /sys/module/NAME
> 
> What I was reacting to is that this patch proposes:
> 
> 	/sys/bus/pci/slots/$slot/module -> /sys/module/NAME
> 
> This scheme is fine as long as only PCI hotplug modules create
> those $slot entries.
> 
> But it is limiting, if in the future, we teach the PCI core to
> create $slot entries when a low level device driver, say tg3 or
> whatever, is loaded.
> 
> In that scenario, it would be more logical if module pointed at
> the LLDD's module, not whatever PCI hotplug module happens to
> claim that slot

It doesn't make any sense for a module like tg3 to claim a slot.
Slot drivers claim slots; device drivers claim devices.  I think Greg
is right, and we should be using 'module' in this case.

Greg KH June 15, 2009, 8 p.m. UTC | #5

On Mon, Jun 15, 2009 at 01:20:36PM -0600, Alex Chiang wrote:
> * Greg KH <[e-mail]>:
> > On Mon, Jun 15, 2009 at 11:52:31AM -0600, Alex Chiang wrote:
> > > * Kenji Kaneshige <[e-mail]>:
> > > > Create symbolic link to hotplug driver module in the PCI slot
> > > > directory (/sys/bus/pci/slots/<SLOT#>). In the past, we need to load
> > > > hotplug drivers one by one to identify the hotplug driver that handles
> > > > the slot, and it was very inconvenient especially for trouble shooting.
> > > > With this change, we can easily identify the hotplug driver.
> > >  
> > > I think this implementation is much nicer than the previous one.
> > > 
> > > One comment below regarding the symlink name.
> > > 
> > > > Index: 20090612/drivers/pci/slot.c
> > > > ===================================================================
> > > > --- 20090612.orig/drivers/pci/slot.c
> > > > +++ 20090612/drivers/pci/slot.c
> > > > @@ -307,6 +307,45 @@ 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)
> > > > +{
> > > > +	struct hotplug_slot *slot = pci_slot->hotplug;
> > > > +	struct kobject *kobj = NULL;
> > > > +	int no_warn;
> > > > +
> > > > +	if (!slot || !slot->ops)
> > > > +		return;
> > > > +	kobj = kset_find_obj(module_kset, slot->ops->mod_name);
> > > > +	if (!kobj)
> > > > +		return;
> > > > +	no_warn = sysfs_create_link(&pci_slot->kobj, kobj, "module");
> > > 
> > > I would prefer to call this link "hotplug_module" or "hp_module".
> > > The reason is, if we ever decide to create another link for that
> > > slot's low level device driver, we won't be limited by something
> > > that already called "module".
> > 
> > Note that "module" is already used in sysfs, so as long as you are
> > pointing to the same thing that those other symlinks are, you should be
> > fine.  You are pointing to /sys/module/NAME, here, right?
> 
> Looks like the common use of "module" is:
> 
> 	/sys/bus/$bus/drivers/$driver/module -> /sys/module/NAME
> 
> What I was reacting to is that this patch proposes:
> 
> 	/sys/bus/pci/slots/$slot/module -> /sys/module/NAME

Which would be correct.

> This scheme is fine as long as only PCI hotplug modules create
> those $slot entries.

What else would ever create a pci slot?

> But it is limiting, if in the future, we teach the PCI core to
> create $slot entries when a low level device driver, say tg3 or
> whatever, is loaded.

Then the pci core would be the module there, right?  Not the pci driver
that controls the device in the slot.

> In that scenario, it would be more logical if module pointed at
> the LLDD's module, not whatever PCI hotplug module happens to
> claim that slot

Huh?  I'm confused now, why not just leave the code alone in such a
situation, having the module symlink point to the module that controls
the slot?

> Since we're talking about an ABI agreement with userspace, I
> think "hotplug_module" is better for future flexibility.

I disagree, "module" is already part of the ABI, let's not create
something that does the exact same thing, yet is named different :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Alexander Chiang June 15, 2009, 8:14 p.m. UTC | #6

* Greg KH <[e-mail]>:
> On Mon, Jun 15, 2009 at 01:20:36PM -0600, Alex Chiang wrote:
> > Since we're talking about an ABI agreement with userspace, I
> > think "hotplug_module" is better for future flexibility.
> 
> I disagree, "module" is already part of the ABI, let's not create
> something that does the exact same thing, yet is named different :)

Ok ok, you guys win.

I'll go back and add some Reviewed-by's for this patch series. :)

/ac

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Matthew Wilcox June 15, 2009, 8:14 p.m. UTC | #7

On Mon, Jun 15, 2009 at 01:00:45PM -0700, Greg KH wrote:
> > This scheme is fine as long as only PCI hotplug modules create
> > those $slot entries.
> 
> What else would ever create a pci slot?

There are several entities which could _create_ a pci slot (ACPI, PCIe,
DMI, probably some other pieces of firmware).  I'm not sure there's
anything else which could _control_ a pci slot (which is i think what
you meant).

> > But it is limiting, if in the future, we teach the PCI core to
> > create $slot entries when a low level device driver, say tg3 or
> > whatever, is loaded.
> 
> Then the pci core would be the module there, right?  Not the pci driver
> that controls the device in the slot.

I'd argue we should have no module entry for that case, since there
would be nothing to control.

> > Since we're talking about an ABI agreement with userspace, I
> > think "hotplug_module" is better for future flexibility.
> 
> I disagree, "module" is already part of the ABI, let's not create
> something that does the exact same thing, yet is named different :)

Agreed.

Alexander Chiang June 15, 2009, 8:40 p.m. UTC | #8

* Kenji Kaneshige <[e-mail]>:
> Create symbolic link to hotplug driver module in the PCI slot
> directory (/sys/bus/pci/slots/<SLOT#>). In the past, we need to load
> hotplug drivers one by one to identify the hotplug driver that handles
> the slot, and it was very inconvenient especially for trouble shooting.
> With this change, we can easily identify the hotplug driver.
> 
> Signed-off-by: Taku Izumi <[e-mail]>
> Signed-off-by: Kenji Kaneshige <[e-mail]>
> 
> ---
>  Documentation/ABI/testing/sysfs-bus-pci |    7 +++++

Hello Kenji-san,

> Index: 20090612/Documentation/ABI/testing/sysfs-bus-pci
> ===================================================================
> --- 20090612.orig/Documentation/ABI/testing/sysfs-bus-pci
> +++ 20090612/Documentation/ABI/testing/sysfs-bus-pci
> @@ -122,3 +122,10 @@ Description:
>  		This symbolic link appears when a device is a Virtual Function.
>  		The symbolic link points to the PCI device sysfs entry of the
>  		Physical Function this device associates with.
> +
> +What:		/sys/bus/pci/slots/.../module
> +Date:		June 2009
> +Contact:	Kenji Kaneshige <[e-mail]>

Are you sure you want to put your contact information here?
Typically, I've used the [e-mail] list as the
contact when documenting new files in Documentation/ABI/

Anyhow, if you want to keep it this way, I'm fine with it.

Reviewed-by: Alex Chiang <[e-mail]>

> +Description:
> +		This symbolic link points to the PCI hotplug controller driver
> +		module that manages the hotplug slot.
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Kenji Kaneshige June 16, 2009, 12:20 a.m. UTC | #9

Alex Chiang wrote:
> * Kenji Kaneshige <[e-mail]>:
>> Create symbolic link to hotplug driver module in the PCI slot
>> directory (/sys/bus/pci/slots/<SLOT#>). In the past, we need to load
>> hotplug drivers one by one to identify the hotplug driver that handles
>> the slot, and it was very inconvenient especially for trouble shooting.
>> With this change, we can easily identify the hotplug driver.
>>
>> Signed-off-by: Taku Izumi <[e-mail]>
>> Signed-off-by: Kenji Kaneshige <[e-mail]>
>>
>> ---
>>  Documentation/ABI/testing/sysfs-bus-pci |    7 +++++
> 
> Hello Kenji-san,
> 
>> Index: 20090612/Documentation/ABI/testing/sysfs-bus-pci
>> ===================================================================
>> --- 20090612.orig/Documentation/ABI/testing/sysfs-bus-pci
>> +++ 20090612/Documentation/ABI/testing/sysfs-bus-pci
>> @@ -122,3 +122,10 @@ Description:
>>  		This symbolic link appears when a device is a Virtual Function.
>>  		The symbolic link points to the PCI device sysfs entry of the
>>  		Physical Function this device associates with.
>> +
>> +What:		/sys/bus/pci/slots/.../module
>> +Date:		June 2009
>> +Contact:	Kenji Kaneshige <[e-mail]>
> 
> Are you sure you want to put your contact information here?

Of course, NO :)

> Typically, I've used the [e-mail] list as the
> contact when documenting new files in Documentation/ABI/

Thank you for your kind advice. I'll update the patch.

Thanks,
Kenji Kaneshige


> 
> Anyhow, if you want to keep it this way, I'm fine with it.
> 
> Reviewed-by: Alex Chiang <[e-mail]>
> 
>> +Description:
>> +		This symbolic link points to the PCI hotplug controller driver
>> +		module that manages the hotplug slot.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

Index: 20090612/drivers/pci/hotplug/pci_hotplug_core.c
===================================================================
--- 20090612.orig/drivers/pci/hotplug/pci_hotplug_core.c
+++ 20090612/drivers/pci/hotplug/pci_hotplug_core.c
@@ -424,6 +424,9 @@  static int fs_add_slot(struct pci_slot *
 {
 	int retval = 0;
 
+	/* Create symbolic link to the hotplug driver module */
+	pci_hp_create_module_link(slot);
+
 	if (has_power_file(slot)) {
 		retval = sysfs_create_file(&slot->kobj,
 					   &hotplug_slot_attr_power.attr);
@@ -498,6 +501,7 @@  exit_attention:
 	if (has_power_file(slot))
 		sysfs_remove_file(&slot->kobj, &hotplug_slot_attr_power.attr);
 exit_power:
+	pci_hp_remove_module_link(slot);
 exit:
 	return retval;
 }
@@ -528,6 +532,8 @@  static void fs_remove_slot(struct pci_sl
 
 	if (has_test_file(slot))
 		sysfs_remove_file(&slot->kobj, &hotplug_slot_attr_test.attr);
+
+	pci_hp_remove_module_link(slot);
 }
 
 static struct hotplug_slot *get_slot_from_name (const char *name)
@@ -544,10 +550,10 @@  static struct hotplug_slot *get_slot_fro
 }
 
 /**
- * pci_hp_register - register a hotplug_slot with the PCI hotplug subsystem
+ * __pci_hp_register - register a hotplug_slot with the PCI hotplug subsystem
  * @bus: bus this slot is on
  * @slot: pointer to the &struct hotplug_slot to register
- * @slot_nr: slot number
+ * @devnr: device number
  * @name: name registered with kobject core
  *
  * Registers a hotplug slot with the pci hotplug subsystem, which will allow
@@ -555,8 +561,9 @@  static struct hotplug_slot *get_slot_fro
  *
  * Returns 0 if successful, anything else for an error.
  */
-int pci_hp_register(struct hotplug_slot *slot, struct pci_bus *bus, int slot_nr,
-			const char *name)
+int __pci_hp_register(struct hotplug_slot *slot, struct pci_bus *bus,
+		      int devnr, const char *name,
+		      struct module *owner, const char *mod_name)
 {
 	int result;
 	struct pci_slot *pci_slot;
@@ -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);
 	/*
 	 * No problems if we call this interface from both ACPI_PCI_SLOT
 	 * driver and call it here again. If we've already created the
 	 * pci_slot, the interface will simply bump the refcount.
 	 */
-	pci_slot = pci_create_slot(bus, slot_nr, name, slot);
+	pci_slot = pci_create_slot(bus, devnr, name, slot);
 	if (IS_ERR(pci_slot)) {
 		result = PTR_ERR(pci_slot);
 		goto out;
@@ -688,6 +697,6 @@  MODULE_LICENSE("GPL");
 module_param(debug, bool, 0644);
 MODULE_PARM_DESC(debug, "Debugging mode enabled or not");
 
-EXPORT_SYMBOL_GPL(pci_hp_register);
+EXPORT_SYMBOL_GPL(__pci_hp_register);
 EXPORT_SYMBOL_GPL(pci_hp_deregister);
 EXPORT_SYMBOL_GPL(pci_hp_change_slot_info);
Index: 20090612/include/linux/pci_hotplug.h
===================================================================
--- 20090612.orig/include/linux/pci_hotplug.h
+++ 20090612/include/linux/pci_hotplug.h
@@ -69,6 +69,7 @@  enum pcie_link_speed {
 /**
  * struct hotplug_slot_ops -the callbacks that the hotplug pci core can use
  * @owner: The module owner of this structure
+ * @mod_name: The module name (KBUILD_MODNAME) of this structure
  * @enable_slot: Called when the user wants to enable a specific pci slot
  * @disable_slot: Called when the user wants to disable a specific pci slot
  * @set_attention_status: Called to set the specific slot's attention LED to
@@ -101,6 +102,7 @@  enum pcie_link_speed {
  */
 struct hotplug_slot_ops {
 	struct module *owner;
+	const char *mod_name;
 	int (*enable_slot)		(struct hotplug_slot *slot);
 	int (*disable_slot)		(struct hotplug_slot *slot);
 	int (*set_attention_status)	(struct hotplug_slot *slot, u8 value);
@@ -159,12 +161,21 @@  static inline const char *hotplug_slot_n
 	return pci_slot_name(slot->pci_slot);
 }
 
-extern int pci_hp_register(struct hotplug_slot *, struct pci_bus *, int nr,
-			   const char *name);
+extern int __pci_hp_register(struct hotplug_slot *slot, struct pci_bus *pbus,
+			     int nr, const char *name,
+			     struct module *owner, const char *mod_name);
 extern int pci_hp_deregister(struct hotplug_slot *slot);
 extern int __must_check pci_hp_change_slot_info	(struct hotplug_slot *slot,
 						 struct hotplug_slot_info *info);
 
+static inline int pci_hp_register(struct hotplug_slot *slot,
+				  struct pci_bus *pbus,
+				  int devnr, const char *name)
+{
+	return __pci_hp_register(slot, pbus, devnr, name,
+				 THIS_MODULE, KBUILD_MODNAME);
+}
+
 /* PCI Setting Record (Type 0) */
 struct hpp_type0 {
 	u32 revision;
Index: 20090612/drivers/pci/slot.c
===================================================================
--- 20090612.orig/drivers/pci/slot.c
+++ 20090612/drivers/pci/slot.c
@@ -307,6 +307,45 @@  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)
+{
+	struct hotplug_slot *slot = pci_slot->hotplug;
+	struct kobject *kobj = NULL;
+	int no_warn;
+
+	if (!slot || !slot->ops)
+		return;
+	kobj = kset_find_obj(module_kset, slot->ops->mod_name);
+	if (!kobj)
+		return;
+	no_warn = sysfs_create_link(&pci_slot->kobj, kobj, "module");
+	kobject_put(kobj);
+}
+EXPORT_SYMBOL_GPL(pci_hp_create_module_link);
+
+/**
+ * pci_hp_remove_link - remove symbolic link to the hotplug driver module.
+ * @slot: struct pci_slot
+ *
+ * Helper function for pci_hotplug_core.c to remove symbolic link to
+ * the hotplug driver module.
+ */
+void pci_hp_remove_module_link(struct pci_slot *pci_slot)
+{
+	sysfs_remove_link(&pci_slot->kobj, "module");
+}
+EXPORT_SYMBOL_GPL(pci_hp_remove_module_link);
+#endif
+
 static int pci_slot_init(void)
 {
 	struct kset *pci_bus_kset;
Index: 20090612/include/linux/pci.h
===================================================================
--- 20090612.orig/include/linux/pci.h
+++ 20090612/include/linux/pci.h
@@ -1261,5 +1261,10 @@  static inline irqreturn_t pci_sriov_migr
 }
 #endif
 
+#if defined(CONFIG_HOTPLUG_PCI) || defined(CONFIG_HOTPLUG_PCI_MODULE)
+extern void pci_hp_create_module_link(struct pci_slot *pci_slot);
+extern void pci_hp_remove_module_link(struct pci_slot *pci_slot);
+#endif
+
 #endif /* __KERNEL__ */
 #endif /* LINUX_PCI_H */
Index: 20090612/Documentation/ABI/testing/sysfs-bus-pci
===================================================================
--- 20090612.orig/Documentation/ABI/testing/sysfs-bus-pci
+++ 20090612/Documentation/ABI/testing/sysfs-bus-pci
@@ -122,3 +122,10 @@  Description:
 		This symbolic link appears when a device is a Virtual Function.
 		The symbolic link points to the PCI device sysfs entry of the
 		Physical Function this device associates with.
+
+What:		/sys/bus/pci/slots/.../module
+Date:		June 2009
+Contact:	Kenji Kaneshige <[e-mail]>
+Description:
+		This symbolic link points to the PCI hotplug controller driver
+		module that manages the hotplug slot.