On Sun, 2009-01-18 at 01:30 +0100, Rafael J. Wysocki wrote: > On PCs we have to restore the config spaces before calling pci_enable_device(), > because otherwise we have a problem with unconfigured devices being enabled > during resume. > > Recently it's turned out that in fact we need to call pci_restore_state() with > interrupts off and power up the device using the PCI PM native mechanism or we > have a problem with shared interrupts. A patch for that was sent yesterday. > > At the same time we can't call pci_enable_device() with interrupts off. > > If there are systems on which the standard config spaces of PCI devices are not > accessible during resume, they are broken at the moment and quite frankly I > don't know what to do to fix them. I haven't seen any reports of this type of > breakage yet, though. Well, it's all a bit fishy... Part of the problem is that pci_enable_device() is the only chance the platform gets to do things like turn power or clocks on for devices that aren't strictly following PCI D states. For PowerMac, we get away with it I think mostly because all devices that are in this case also have explicit calls to the platform code to turn things on. But I can very well see embedded systems having trouble in that area. I suppose when it happens, it would be a matter of having the right arch hook inside pci_restore_state() itself. As for the problem with interrupts, maybe the right option here is to have the PCI core always restore the state early ? Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
