Comment 10 for bug 1483054

Hope this is of some use to diagnose the issue further. I have the following observations from a Macbook pro that wakes immediately after suspend

```
cat /proc/acpi/wakeup Device S-state Status Sysfs node
P0P2 S3 *disabled pci:0000:00:01.0
GFX0 S3 *disabled pci:0000:01:00.0
PEG1 S3 *disabled pci:0000:00:01.1
EC S4 *disabled platform:PNP0C09:00
GMUX S3 *disabled pnp:00:03
HDEF S3 *disabled pci:0000:00:1b.0
RP03 S3 *disabled pci:0000:00:1c.2
ARPT S4 *disabled pci:0000:03:00.0
RP04 S3 *disabled pci:0000:00:1c.3
RP05 S3 *disabled pci:0000:00:1c.4
XHC1 S3 *enabled pci:0000:00:14.0
ADP1 S4 *disabled platform:ACPI0003:00
LID0 S4 *enabled platform:PNP0C0D:00
```

Note two ACPI wakeup sources - XHC1 and LID0 (XHC1 is USB - eg for external keyboards, LID0 is the lid). Now you can toggle their wakeup powers as follows

```
$ echo XHC1 | sudo tee /proc/acpi/wakeup
$ echo LID0 | sudo tee /proc/acpi/wakeup
```

(Note with both XHC1 and LID disabled only the power-button will wake you)

What I see: (Truth table)

  XHC1 | LID0 | Result
  disabled | disabled | Stays asleep until power button hit
  enabled | enabled | Wake after 2.5 seconds sleep
  enabled | disabled | Wake after 2.5 seconds sleep
  disabled | enabled | Stays asleep if lid left closed
             | | Wake after 2.5 seconds sleep if lid left open

From this I infer that something on the USB bus (or the USB driver itself) is causing a wake - I can't find a culprit device on the bus.

From this I also infer that the lid state reports regularly - ie its not the act of opening that causes the wake its the fact of it being open.

So by disabling just XHC1 I lose keyboard wake, but I can close the lid to sleep and open it to wake which is just about workable for me.

Hope that helps