PCI powerstate issues

Thanks for your work on this.  My laptop functions as normal, including
good suspend/resume.  There are some minor issues I've found when running
with hw.pci.do_powerstate=1.

It appears my winmodem can't be put in D3.  Here's the portion of the
boot:

pcib2: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci2: <ACPI PCI bus> on pcib2
pcib2: slot 0 INTA is routed to irq 11
pcib2: slot 0 INTB is routed to irq 11
pcib2: slot 2 INTA is routed to irq 11
pcib2: slot 8 INTA is routed to irq 11
cbb0: <TI1420 PCI-CardBus Bridge> mem 0x50000000-0x50000fff irq 11 at device 0.0 on pci2
cbb0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x50000000
cardbus0: <CardBus bus> on cbb0
pccard0: <16-bit PCCard bus> on cbb0
cbb1: <TI1420 PCI-CardBus Bridge> mem 0x51000000-0x51000fff irq 11 at device 0.1 on pci2
cbb1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x51000000
cardbus1: <CardBus bus> on cbb1
pccard1: <16-bit PCCard bus> on cbb1
pci2: <simple comms> at device 2.0 (no driver attached)
pci2:2:0: Transition from D0 to D3
pci2: Failed to set ACPI power state D3 on (null): AE_BAD_PARAMETER

This device is:
none5_at_pci2:2:0: class=0x078000 card=0x04101468 chip=0x044911c1 rev=0x01 hdr=0x00
    vendor   = 'Lucent/Agere Systems (Was: AT&T MicroElectronics)'
    device   = 'LT Winmodem 56k'
    class    = simple comms

In looking at my ASL, I can't seem to find this driver defined there.  It
appears pci2 is not listed.  I tested and indeed it had a null handle.  I
just committed a check for this to acpi_pci.c.  I don't think the acpi
power functions are safe against a null pointer (looks like it adds a
consumer with that handle).  I added a check for that so now it's ok there
too.

Also, I tried loading a usb driver after boot to see if it powered on the
devices properly:

pci0: driver added
pci0:29:0: reprobing on driver added
uhci0: <Intel 82801CA/CAM (ICH3) USB controller USB-A> port 0x1800-0x181f irq 11
 at device 29.0 on pci0
uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1800
uhci0: [GIANT-LOCKED]
usb0: <Intel 82801CA/CAM (ICH3) USB controller USB-A> on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
pci0:29:1: reprobing on driver added
uhci1: <Intel 82801CA/CAM (ICH3) USB controller USB-B> port 0x1820-0x183f irq 11
 at device 29.1 on pci0
uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1820
uhci1: [GIANT-LOCKED]
usb1: <Intel 82801CA/CAM (ICH3) USB controller USB-B> on uhci1
usb1: USB revision 1.0
uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
pci0:29:2: reprobing on driver added
uhci2: <Intel 82801CA/CAM (ICH3) USB controller USB-C> port 0x1840-0x185f irq 11
 at device 29.2 on pci0
uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1840
uhci2: [GIANT-LOCKED]
usb2: <Intel 82801CA/CAM (ICH3) USB controller USB-C> on uhci2
usb2: USB revision 1.0
uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
pci0:31:5: reprobing on driver added
pci0:31:5: Transition from D0 to D3
pci1: driver added
pci1:0:0: reprobing on driver added
pci2: driver added
pci2:2:0: reprobing on driver added
pci2:2:0: Transition from D0 to D3
pci2: Failed to set ACPI power state D3 on (null): AE_BAD_PARAMETER
pci0: driver added
pci0:31:5: reprobing on driver added
pci0:31:5: Transition from D0 to D3
pci1: driver added
pci1:0:0: reprobing on driver added
pci2: driver added
pci2:2:0: reprobing on driver added
pci2:2:0: Transition from D3 to D0
pci0: driver added
pci0:31:5: reprobing on driver added
pci0:31:5: Transition from D0 to D3
pci1: driver added
pci1:0:0: reprobing on driver added
pci2: driver added
pci2:2:0: reprobing on driver added
pci2:2:0: Transition from D3 to D0

This is weird.  It appears you don't power devices up to D0 for the scan.
Isn't that necessary so they can respond to the probe?  Or are the config
registers guaranteed to be valid even when the device is in D3.  Also,
since all these devices were already in D3, it's redundant to do the
D0->D3 transition on them.  Does that mean we're not properly tracking
current state?  Or were these silently switched to D0 before the probe?

-Nate