On Fri, 28 Nov 2008, Rolf Eike Beer wrote: > Trent Piepho wrote: > > On Wed, 26 Nov 2008, Darrick J. Wong wrote: > > > On Wed, Nov 26, 2008 at 03:55:35PM -0700, Alex Chiang wrote: > > > > > Maybe it's different on powerpc then? My pseudo-hotplugable device > > > > > is also the only thing connected to the PCI-E host bus controller. > > > > > At boot the controller is empty and so I think some code to enable > > > > > its BARs gets skipped. But without the pci_enable_device(), I get > > > > > this: > > > > > > > > > > 01:00.0 Signal processing controller: Freescale Semiconductor Inc > > > > > Aurora Nexus Trace Interface Flags: fast devsel, IRQ 255 > > > > > Memory at 40000000 (64-bit, prefetchable) [disabled] > > > > > [size=4K] > > > > > > Are you referring to this? ^^^^^^^^^^ > > > > > > Without seeing the raw dump of the PCI config space, it looks to me like > > > the memory space enable bit of the PCICMD register is unset. Probably > > > the device driver should call pci_enable_device() at init time, though I > > > suppose you did say earlier that there is no driver. > > > > Yes, that's it. It seems like since the BARs are normally enabled after a > > device is scanned at boot time that they should also be enabled when a > > device is found by a fakephp rescan. So I thought it seemed reasonable to > > put pci_enable_device() in fakephp. > > No, pci_enable_device() will be called by the device driver. The hotplug > drivers have nothing to do with that. I guess you didn't read the part about there not being a device driver? Why should a device added by fakephp be configured differently than one added at boot time? Is there something that will break if fakephp enables devices it finds? -- 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
