Is there a user space pci rescan method?

Hi,

Is there a user space or perhaps simple kernel module way to rescan
the pci bus? I currently have a user mode program modify the pci bus,

but I can not push the user mode program to the bios for reasons I can't get in to.

Hi,

I know very little about hotplug, but does make sense.
How do you motivate a hotplug insertion event? Or should I just go read the /docs on hotplugging? Any help is Appreciated:)

Quoted 6 lines · Dave Aubin

Hi,

I know very little about hotplug, but does make sense.
How do you motivate a hotplug insertion event? Or should I just go read the /docs on hotplugging? Any help is Appreciated:)

There is a "fake" hotplug driver which works for normal pci. But last time I looked at it, it did only support hot disabling, not hot enabling
- but this surely can be fixed.

Quoted 9 lines · Jan Dittmer

Quoted 6 lines · Dave Aubin

Hi,

I know very little about hotplug, but does make sense.
How do you motivate a hotplug insertion event? Or should I just go read the /docs on hotplugging? Any help is Appreciated:)

Quoted 3 lines

There is a "fake" hotplug driver which works for normal pci. But last time I looked at it, it did only support hot disabling, not hot enabling
- but this surely can be fixed.

Yes, hot "enabling" has been left for someone to add to the driver, if you read the comments in it :)

Quoted 9 lines · Greg KH

Quoted 8 lines · Jan Dittmer

Quoted 6 lines · Dave Aubin

Hi,

I know very little about hotplug, but does make sense.
How do you motivate a hotplug insertion event? Or should I just go read the /docs on hotplugging? Any help is Appreciated:)

Quoted 6 lines

Quoted 3 lines

There is a "fake" hotplug driver which works for normal pci. But last time I looked at it, it did only support hot disabling, not hot enabling
- but this surely can be fixed.

Yes, hot "enabling" has been left for someone to add to the driver, if you read the comments in it :)

I read them and started playing around with this driver. So echoing 0 in
/sys/bus/pci/slots/*/power disables the pci device. The problem I see
is, that the tree with the device is disappearing. So how am I supposed to re-enable the device. I've no real hotplug hardware to play with, so I'm bound to reading the source code in drivers/pci/hotplug and testing with fakephp. I found your utility pcihpview (v0.5) which searches for /sys/bus/pci/hotplug_slots. But grepping the kernel tree doesn't show any mentioning of it - so I suppose it is outdated.
Is there anywhere a current article (or Documentation/pci_hotplug.txt) about the state of PCI hotplug and how this is supposed to work?

Just search the archive of [email protected] for dummyphp, this is the version that works. I'll rediff it soon and hope Greg will accept it this time.

Message-Id to search for: <[email protected]>

Quoted 5 lines · Rolf Eike Beer

Just search the archive of [email protected] for dummyphp, this is the version that works. I'll rediff it soon and hope Greg will accept it this time.

Message-Id to search for: <[email protected]>

You didn't read my p.s. ... I found it and it's working quite nice. Already

discovered a bug in dv1394. Just one thing: Can you strip DUMMY- from the name in /sys/bus/pci/slots/ ? It's really ugly and you can't mix different hotplug drivers anyway.

Quoted 10 lines · Jan Dittmer

Quoted 6 lines · Rolf Eike Beer

Just search the archive of [email protected] for dummyphp, this is the version that works. I'll rediff it soon and hope Greg will accept it this time.

Message-Id to search for:
<[email protected]>

You didn't read my p.s. ... I found it and it's working quite nice. Already

Ehm, yes. Sorry, around 1900 local time and no real breakfast until now.

Quoted 3 lines

discovered a bug in dv1394. Just one thing: Can you strip DUMMY- from the name in /sys/bus/pci/slots/ ? It's really ugly and you can't mix different hotplug drivers anyway.

Sounds reasonable.

Ok, here we go. This is my current diff that I use for my tests at home. It adds dummyphp and cleans up fakephp a lot (read: kills it). Changes from last version:

(quoted diff) +0 -5

-removed some dead comments
-removed some unused instructions
-reordered allocation in add_slot to do less memory allocations if there is
 no device in slot
-changed param "usedonly" to "showunused" so it behaves like fakephp at the
 first look: if you load dummyphp without parameters there are only slots with
 devices in it.
-removed "DUMMY-" prefix to entries in /sys/bus/pci/slots/

Please send comments so I can send it for inclusion soon.

Quoted 13 lines · Rolf Eike Beer

Ok, here we go. This is my current diff that I use for my tests at home. It adds dummyphp and cleans up fakephp a lot (read: kills it). Changes from last version:

(quoted diff) +0 -3

-removed some dead comments
-removed some unused instructions
-reordered allocation in add_slot to do less memory allocations if there

is no device in slot
-changed param "usedonly" to "showunused" so it behaves like fakephp at the first look: if you load dummyphp without parameters there are only slots with devices in it.
-removed "DUMMY-" prefix to entries in /sys/bus/pci/slots/

Quoted 1 line

Please send comments so I can send it for inclusion soon.

Well, first of all I think you should just submit a patch to add dummyphp and not removing fakephp in the same step. Also you somehow mis-copied the

patch to your mail app - most (not all) tabs are converted to one space (or is it just thunderbird displaying the mail?). Can you resend it? Then I'll

give it a try. Greg wrote in another mail that the 'proper' way of 'powering up' device slots should be to rescan the entire bus. I don't know, your approach certainly seems easier, but you are bound to either display all pci slots which may come to live or just the ones in the system already, which means you cannot rescan slots which weren't equipped on boot up. So perhaps adding a rescan method to fakephp is indeed cleaner.

Normally you will just remove and bring back one or two cards in the system (e.g. your NIC or sound card, depending on xmms or irc being on top of your priority list *g*). So from my point of view it's a good idea to keep the slot dirs on remove so you can just go back in your command history and replace 0 with 1 to get the device back. I don't see why bus structure or whatever may ever change so rescanning the whole bus is IMHO a bit overkill.

Quoted 7 lines · Rolf Eike Beer

Normally you will just remove and bring back one or two cards in the system (e.g. your NIC or sound card, depending on xmms or irc being on top of your priority list *g*). So from my point of view it's a good idea to keep the slot dirs on remove so you can just go back in your command history and replace 0 with 1 to get the device back. I don't see why bus structure or whatever may ever change so rescanning the whole bus is IMHO a bit overkill.

My point was, I load dummyphp with showunused=0 and only get dirs for the slots with devices in them. Now I decide to put a network card (or whatever I have to spare) in an empty slot, hope that the system doesn't reboot immediately, and voila I don't have any /sys/bus/pci/slots dir to enable the slot and have to reboot nevertheless. Or does the pci system a rescan if I reinsert the module?

Am Freitag, 24. September 2004 14:16 schrieben Sie:

Quoted 9 lines

Quoted 7 lines · Rolf Eike Beer

Normally you will just remove and bring back one or two cards in the system (e.g. your NIC or sound card, depending on xmms or irc being on top of your priority list *g*). So from my point of view it's a good idea to keep the slot dirs on remove so you can just go back in your command history and replace 0 with 1 to get the device back. I don't see why bus structure or whatever may ever change so rescanning the whole bus is IMHO a bit overkill.

Quoted 6 lines

My point was, I load dummyphp with showunused=0 and only get dirs for the slots with devices in them. Now I decide to put a network card (or whatever I have to spare) in an empty slot, hope that the system doesn't reboot immediately, and voila I don't have any /sys/bus/pci/slots dir to enable the slot and have to reboot nevertheless. Or does the pci system a rescan if I reinsert the module?

In this case you have to "rmmod dummyphp; modprobe dummyphp showunused=1" to get all slots and try to enable the device. We have tested it once with a special PCI debugging board where we can electrically disable the PCI bus so we don't kill our hardware. The problem was that on reenabling a interrupt storm killed the machine, I don't remember the exact problem. IIRC it looked like the kernel found the device but the PCI bridge got confused by the new device (or something like this). I don't know if there is a way to survive this situation as the bridges in "normal" hardware are not hotplug aware. Greg?

Quoted 8 lines

to get all slots and try to enable the device. We have tested it once with a special PCI debugging board where we can electrically disable the PCI bus so we don't kill our hardware. The problem was that on reenabling a interrupt storm killed the machine, I don't remember the exact problem. IIRC it looked like the kernel found the device but the PCI bridge got confused by the new device (or something like this). I don't know if there is a way to survive this situation as the bridges in "normal" hardware are not hotplug aware. Greg?

Hm, don't know, but that's the whole reason people want this, so it should work :)

The main reason I don't like showing _all_ possible pci devices like dummyphp does is that it doesn't handle adding a new device (like you just said), and the fact that you forgot to handle pci domains. If you add support for PCI domains, then the list of files in that directory will pretty much be unusable.

Please just add the "rescan" support to fakephp, and everyone will be happy...

Please just add the "rescan" support to fakephp, and everyone will be happy...

Quoted 2 lines · Greg KH

Please just add the "rescan" support to fakephp, and everyone will be happy...

Well, I started to work on this for fun. What I currently have is a stand-alone module which rescans the pci bus on insert and enables previously disabled devices. This works (at least with my ieee1394 port). Problem is, that fakephp does not get notified about this new pci device and no new file is created in /sys/bus/pci/slots. So I'm going to add this rescan functionality directly to fakephp.
Question is: where? My current idea is a fake hotplug slot "rescan" in /sys/bus/pci/slots , where you can write "1" into the "power" attribute. FWIW I've attached the standalone module and a kernel patch which rips out the pci_bus_add_device functionality from pci_bus_add_devices.

Quoted 7 lines · Jan Dittmer

Quoted 2 lines · Greg KH

Please just add the "rescan" support to fakephp, and everyone will be happy...

Quoted 10 lines

Well, I started to work on this for fun. What I currently have is a stand-alone module which rescans the pci bus on insert and enables previously disabled devices. This works (at least with my ieee1394 port). Problem is, that fakephp does not get notified about this new pci device and no new file is created in /sys/bus/pci/slots. So I'm going to add this rescan functionality directly to fakephp.
Question is: where? My current idea is a fake hotplug slot "rescan" in /sys/bus/pci/slots , where you can write "1" into the "power" attribute. FWIW I've attached the standalone module and a kernel patch which rips out the pci_bus_add_device functionality from pci_bus_add_devices.

Well, here is a quick & dirty hack, which adds this function to enable_slot in fakephp. So if you write "1" in the power attribute of any slot, the whole bus gets rescanned (you still need the pci_bus_add_device.patch from the previous mail).

Quoted 21 lines · Jan Dittmer

Quoted 17 lines · Jan Dittmer

Quoted 2 lines · Greg KH

Please just add the "rescan" support to fakephp, and everyone will be happy...

Well, I started to work on this for fun. What I currently have is a stand-alone module which rescans the pci bus on insert and enables previously disabled devices. This works (at least with my ieee1394 port). Problem is, that fakephp does not get notified about this new pci device and no new file is created in /sys/bus/pci/slots. So I'm going to add this rescan functionality directly to fakephp.
Question is: where? My current idea is a fake hotplug slot "rescan" in /sys/bus/pci/slots , where you can write "1" into the "power" attribute. FWIW I've attached the standalone module and a kernel patch which rips out the pci_bus_add_device functionality from pci_bus_add_devices.

Quoted 4 lines

Well, here is a quick & dirty hack, which adds this function to enable_slot in fakephp. So if you write "1" in the power attribute of any slot, the whole bus gets rescanned (you still need the pci_bus_add_device.patch from the previous mail).

Well one last update. This version also handles deactivation of subfunctions correctly, ie. when the parent should be disabled, all subfunctions will be disabled first.

fakephp needs to add newly discovered devices to the global pci list. Therefore seperate out the appropriate chunk from pci_bus_add_devices to pci_bus_add_device to add a single device to sysfs, procfs and the global device list.

Signed-off-by Jan Dittmer <[email protected]>

===== drivers/pci/bus.c 1.9 vs edited =====

Quoted 6 lines · Jan Dittmer

fakephp needs to add newly discovered devices to the global pci list. Therefore seperate out the appropriate chunk from pci_bus_add_devices to pci_bus_add_device to add a single device to sysfs, procfs and the global device list.

Signed-off-by Jan Dittmer <[email protected]>

the brace should go to a line of it's own

Quoted 7 lines · Christoph Hellwig

Quoted 5 lines · Jan Dittmer

fakephp needs to add newly discovered devices to the global pci list. Therefore seperate out the appropriate chunk from pci_bus_add_devices to pci_bus_add_device to add a single device to sysfs, procfs and the global device list.

Quoted 3 lines

Quoted 1 line

Signed-off-by Jan Dittmer <[email protected]>

the brace should go to a line of it's own

Sorry about that, updated patch follows:

Quoted 14 lines · Jan Dittmer

Quoted 11 lines · Christoph Hellwig

Quoted 6 lines · Jan Dittmer

fakephp needs to add newly discovered devices to the global pci list. Therefore seperate out the appropriate chunk from pci_bus_add_devices to pci_bus_add_device to add a single device to sysfs, procfs and the global device list.

Signed-off-by Jan Dittmer <[email protected]>

the brace should go to a line of it's own

Quoted 1 line

Sorry about that, updated patch follows:

Ugh, your email client ate all of the tabs and spit them out as spaces for this patch :(

Care to try it again?

Quoted 19 lines · Greg KH

Quoted 15 lines · Jan Dittmer

Quoted 11 lines · Christoph Hellwig

Quoted 6 lines · Jan Dittmer

fakephp needs to add newly discovered devices to the global pci list. Therefore seperate out the appropriate chunk from pci_bus_add_devices to pci_bus_add_device to add a single device to sysfs, procfs and the global device list.

Signed-off-by Jan Dittmer <[email protected]>

the brace should go to a line of it's own

Sorry about that, updated patch follows:

Quoted 4 lines

Ugh, your email client ate all of the tabs and spit them out as spaces for this patch :(

Care to try it again?

Well, I still don't know how to do this with Thunderbird as non attachment. So here it goes as attachment.

This adds the ability to rescan the pci bus for newly inserted, reprogrammed or previously disabled pci devices.
To initiate a rescan you need to write '1' to any of the /sys/bus/pci/slots/*/power control files. No known pci devices will be touched.
Additionally this fixes a bug, when someone tries to disable a device with subfunctions. The subfunctions will be disabled first now.

My point was, I load dummyphp with showunused=0 and only get dirs for the slots with devices in them. Now I decide to put a network card (or whatever I have to spare) in an empty slot, hope that the system doesn't reboot immediately, and voila I don't have any /sys/bus/pci/slots dir to enable the slot and have to reboot nevertheless. Or does the pci system a rescan if I reinsert the module?

Quoted 6 lines

My point was, I load dummyphp with showunused=0 and only get dirs for the slots with devices in them. Now I decide to put a network card (or whatever I have to spare) in an empty slot, hope that the system doesn't reboot immediately, and voila I don't have any /sys/bus/pci/slots dir to enable the slot and have to reboot nevertheless. Or does the pci system a rescan if I reinsert the module?

That is DANGEROUS and WILL DESTROY YOUR SYSTEM. Under no circumstances should we be encouraging people to do that.

-changed param "usedonly" to "showunused" so it behaves like fakephp at the
first look: if you load dummyphp without parameters there are only slots with devices in it.

Quoted 3 lines · Rolf Eike Beer

-changed param "usedonly" to "showunused" so it behaves like fakephp at the first look: if you load dummyphp without parameters there are only slots with devices in it.

Well, know I get only entries for all devices I don't have!

drivers/pci/hotplug/dummyphp.c 2004-09-23 23:11:23.000000000 +0200 line 145

Quoted 6 lines

+ dslot->dev = pci_get_slot(dslot->bus, dslot->devfn);

drivers/pci/hotplug/dummyphp.c 2004-09-23 23:11:23.000000000 +0200 renamed from drivers/pci/hotplug/dummyphp.c 1970-01-01 01:00:00.000000000 +0100 +5 -0

+
+ if (showunused || dslot->dev) {
+  retval = 0;
+  goto error_dslot;
+ }

This should probably be !showunused || !dslot->dev ?

Quoted 16 lines · Greg KH

Quoted 12 lines · Jan Dittmer

Quoted 6 lines · Dave Aubin

Hi,

I know very little about hotplug, but does make sense.
How do you motivate a hotplug insertion event? Or should I just go read the /docs on hotplugging? Any help is Appreciated:)

There is a "fake" hotplug driver which works for normal pci. But last time I looked at it, it did only support hot disabling, not hot enabling
- but this surely can be fixed.

Quoted 3 lines

Yes, hot "enabling" has been left for someone to add to the driver, if you read the comments in it :)

I read them and started playing around with this driver. So echoing 0 in
/sys/bus/pci/slots/*/power disables the pci device. The problem I see
is, that the tree with the device is disappearing. So how am I supposed to re-enable the device.

I've no real hotplug hardware to play with, so I'm bound to reading the source code in drivers/pci/hotplug and testing with fakephp.

I found your utility pcihpview (v0.5) which searches for /sys/bus/pci/hotplug_slots. But grepping the kernel tree doesn't show any mentioning of it - so I suppose it is outdated.

Is there anywhere a current article (or Documentation/pci_hotplug.txt) about the state of PCI hotplug and how this is supposed to work?

ps: Meanwhile I found dummyphp on the pcihpd mailinglist. This doesn't remove the device from /sys/bus/pci/slots/*/power . Still I'd like to know the offical way.