[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