lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20140721081734.GL3935@laptop> Date: Mon, 21 Jul 2014 10:17:34 +0200 From: Peter Zijlstra <peterz@...radead.org> To: "Rafael J. Wysocki" <rjw@...ysocki.net> Cc: ACPI Devel Maling List <linux-acpi@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Linux PM list <linux-pm@...r.kernel.org>, Linux PCI <linux-pci@...r.kernel.org>, Zhang Rui <rui.zhang@...el.com> Subject: Re: [Update 2x][PATCH 1/2] ACPI / PM: Always enable wakeup GPEs when enabling device wakeup On Mon, Jul 21, 2014 at 01:51:46AM +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@...el.com> > Subject: ACPI / PM: Always enable wakeup GPEs when enabling device wakeup > > Wakeup GPEs are currently only enabled when setting up devices for > remote wakeup at run time. During system-wide transitions they are > enabled by ACPICA at the very last stage of suspend (before asking > the BIOS to take over). Of course, that only works for system > sleep states supported by ACPI, so in particular it doesn't work > for the "freeze" sleep state. > > For this reason, modify the ACPI core device PM code to enable wakeup > GPEs for devices when setting them up for wakeup regardless of whether > that is remote wakeup at runtime or system wakeup. That allows the > same device wakeup setup routine to be used for both runtime PM and > system-wide PM and makes it possible to reduce code size quite a bit. > > That should make things like ACPI-based PCI Wake-on-LAN work with > the "freeze" sleep state among other things. > > Tested-on: Toshiba Portege R500 > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com> > --- > > The PCI ACPI device PM notify handler has to be updated to avoid running > runtime resume callbacks during system suspend too. So I tested the first version, with that my WSM-EP didn't resume on WoL and pressing the power button after the WoL had it crash and burn in the igb driver. Today I tested this latest version and WoL still didn't trigger a resume, but the power button did make it go again, no crashes and I suppose I can confirm the earlier patch that stopped making it go halt works. When I 'halt' I can wake the machine back up using a WoL so that all _should_ work afaik. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists