Comment 37 for bug 1799988

Please enable btusb autosuspend during test.

This is what happened:
[25781.865975] PM: suspend entry (deep)
System is about to suspend to deep (S3),

[25782.016682] pci_pm_suspend(): hcd_pci_suspend+0x0/0x30 returns -16
[25782.016691] dpm_run_callback(): pci_pm_suspend+0x0/0x130 returns -16
[25782.016694] PM: Device 0000:00:14.0 failed to suspend async: error -16
[25782.920799] PM: Some devices failed to suspend, or early wake event detected
But the xHC (USB controller) wakes up early, so the system aborted S3,

[25782.922906] usb usb1-port7: status 0103 change 0004
The one wakes xHC up is btusb, which is woken up by BLE events,

[25783.167977] PM: suspend exit
[25783.168050] PM: suspend entry (s2idle)
System tries to suspend again, via s2idle. This happens more than once.

[25842.804908] PM: suspend entry (deep)
[25842.804912] PM: Syncing filesystems ... done.
[25842.834864] Freezing user space processes ... (elapsed 0.002 seconds) done.
[25842.837207] OOM killer disabled.
[25842.837208] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[25842.838619] Suspending console(s) (use no_console_suspend to debug)

Finally it suspends successfully, but both btusb and ath10k_pci devices fail to work:
[25843.579504] ath10k_pci 0000:02:00.0: Refused to change power state, currently in D3
[25844.303534] usb 1-7: device descriptor read/64, error -71

Most devices' .resume() and .suspend() callbacks rely on full system suspend/resume works successfully. This assumption breaks when the first system suspend fails, which is cause by the BLE event.