do not enable pci bridge decoding on resume until I/O windows are restored

[avg]

Summary

PCI bus driver restores most but not all of a child PCI-PCI bridge
configuration. The bridge's I/O windows are restored by pcib driver and
that happens later in time. This can be problematic because the Command
register is restored before the windows are restored. If the firmware
programs the windows incorrectly or even does not program them at all, then
the bridge can start claiming I/O cycles that are not intended for it. This
will continue until the correct windows are restored.

I have observed this problem with a buggy BIOS where after resuming from S3
an I/O port window of a PCI-PCI bridge was configured with zero base and
limit causing the bridge to claim 0x0 - 0xFFF port range. That interfered
with ACPI port access including ACPI PM Timer at port 0x808, thus wreaking
havoc in the time keeping.

The solution is to restore the Command register of PCI-PCI bridges after the
windows are restored in pcib driver. While here, I decided that for other
PCI device types (normal and cardbus) it's better to restore the Command
register after their BARs are restored.

[avg]

John, I know that you would prefer something grander.
Do you at least not object to this change ?

[imp]

This seems a reasonable fix for the problem at hand... I don't object, but John may have a specific case in mind...

[jhb]

This is probably fine as-is. For some similar problems I actually moved some of the PCI-PCI bridge logic into the PCI bus itself. I wouldn't mind if we did that here. In fact, it is the bus stuff I'm thinking of where we save/restore the bus numbers in the generic PCI layer (I had to change that to make the PCI_BUS_RES stuff work well across suspend/resume). We could save/restore the raw I/O windows themselves in pci_cfg_save/restore which would probably be ok as well, but that's a bit more work. Doing that would basically remove the need for pcib_cfg_save/pcib_cfg_restore entirely.