On Fri, Oct 6, 2017 at 9:24 AM, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: >> On the other hand, the RP05 (root port) _PRW says it will wake up the >> system via GPE09, and the _L09 handler at least has one codepath which >> could potentially do a Notify(PXSX, 2) to indicate an ethernet wakeup. > > Which can only happen in the S0 system state. Not quite sure I understand your comment here. Of course the _L09 handler (and any other ACPI code) can only execute in S0 state. However if Linux leaves GPE09 enabled during S3 suspend, and then detects that it has an event pending on resume, it will execute _L09 during resume. (However, we have not observed GPE09 firing at all) >> But in testing: >> - If GPE08 is enabled as a wakeup source, the system will always wake >> up as soon as it goes to sleep > > What exactly do you mean by "enabled as a wakeup source"? Linux associates the ethernet PCI device with PCI0.RP05.PXSX, which has _PRW referencing GPE08. r8169 has already done device_set_wakeup_enable() at probe time. So when going into suspend, acpi_enable_wakeup_devices() and the code beneath that will ensure that GPE08 is enabled when the system goes into suspend. See acpi_hw_enable_wakeup_gpe_block(). To disable it, "echo disabled > power/wakeup" for the ethernet device in sysfs. To test with GPE09 instead, I modified the _PRW method in the DSDT to point at GPE09, and again used sysfs to control whether the GPE is enabled during suspend or not. Thanks Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
