[linux-pm] [PATCH 084/123] USB: fix up suspend and resume for PCI host controllers

Benjamin Herrenschmidt benh at kernel.crashing.org
Sat Jan 17 17:47:34 PST 2009


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.




More information about the linux-pm mailing list