On Tue, 25 Nov 2008, Darrick J. Wong wrote: > On Tue, Nov 25, 2008 at 08:46:37PM -0800, Trent Piepho wrote: > > > > I've had a patch to fakephp that did something like this for a while, but I > > called pci_bus_assign_resources() _after_ adding the devices with calls to > > pci_bus_add_device(). It seems like that might be easier, to just add all > > the devices and then call pci_bus_assign_resources() when done. It appears > > to work fine for me. Is there a reason this is wrong? > > afaict, pci_bus_add_devices calls device_add to set up sysfs files and > trigger a event that can (ultimately) cause a pci probe action to > happen... but the probe will fail because the resources aren't ready. > In any case, if a device shows up in sysfs I'd assume that to mean that > the device is ready to go--all the BARs are reserved for the device, > etc. For sure, I woudn't expect to be racing > pci_bus_assign_resources(). Ok, that makes sense. The device I'm using fakephp for doesn't have a kernel driver so I wouldn't have noticed that. Have you tested this with a device that isn't present at boot? I found that I needed to a call to pci_enable_device() after assigning resources, otherwise the BARs wouldn't be enabled. This only happened if the device wasn't present at boot time. My hardware doesn't run on the latest kernel so I can't test it. It looks like there have been a bunch of pci hotplug changes so back porting this might not be feasible. It also looks a previous patch by Alex Chiang completely changed the sysfs interface for fakephp. I thought sysfs interfaces were supposed to be stable?! Also looks like it made fakephp useless. How are you supposed to figure out which "fake-n" directory is the right one to disable the device you want? -- 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
