On Saturday 17 January 2009, Benjamin Herrenschmidt wrote: > On Sat, 2009-01-17 at 14:21 +0100, Rafael J. Wysocki wrote: > > On Saturday 17 January 2009, Benjamin Herrenschmidt wrote: > > > > > > > Not exactly. Just try this patch: > > > > > > > > http://marc.info/?l=linux-kernel&m=123184641714487&w=2 > > > > > > > > with vanilla 2.6.29-rc1 or rc2. > > > > > > Out of curiosity, while pci_disable_device() before save_state() ? > > > > Because on resume we call pci_restore_state() before pci_(re)enable_device(). > > But that doesn't sound correct to me. > > In some cases, pci_enable_device() is hooked by the architecture to > effectively turn on the device, ie, enable clocks or power, etc... I've > seen embedded stuff like that and some PowerMac devices do that too > (though not those USB ones in that specific case). > > I think nothing should happen before pci_enable_device() 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. Thanks, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
