On the Surface 3 tablet, I am unable to wake up a device that has been frozen with "echo freeze > /sys/power/state" with any device other than the capacitive "Windows" button or power button on the device. Note: Support for the Windows button and other hardware keys requires patch set from http://www.spinics.net/lists/linux-input/msg44595.html, so anyone without this patch set has no way of unfreezing. Also, https://bugzilla.kernel.org/show_bug.cgi?id=106941#c34 to keep the system from repeatedly suspending, or disable lid switch suspend in /etc/systemd/logind.conf In Windows, this device goes into a "connected standby" (i.e. low-power S0) mode, and can be quickly woken with the Type Cover, or a USB attached mouse. The Type Cover is just a USB device that goes through a hardware DRM implementation. Note that the only device that appears in /proc/acpi/wakeup is "WIFI". I know very little about the power management stuff that happens in USB, but I have some non-technical observations about freeze: * When freeze happens, USB peripherals still have power - a connected USB Hub still has an LED on. * When freeze happens, a connected USB flash drive seems to suspend, its LED goes off * When freeze happens, the connected Type Cover seems to lose power - its LEDs go off, and it does not respond to inputs. * When freeze happens, moving a connected mouse seems to unsuspend the flash drive, its LED comes back on, but the system does not wake up. (Does the USB hub try to wake up everything attached to it?) * Power button and Windows button will wake system. Hardware volume keys will not. From my poor understanding of this system's DSDT, I think that the XHCI controller is supposed to remain powered on, so things connected to it shouldn't be suspending, which might make this an ACPI bug. Or a PM bug. Or a bug in the USB stack.
Created attachment 220701 [details] Surface 3 DSDT
Created attachment 220711 [details] Surface 3 FACP FACP indicates support for "Low Power S0 Idle"
Created attachment 220721 [details] dmesg with freeze echo "freeze" > /dev/kmsg echo "freeze" > /sys/power/state -wakeup- echo "unfreeze" > /dev/kmsg
Created attachment 220731 [details] Output of "cat /proc/acpi/wakeup"
Also note that: echo "enabled" > /sys/bus/usb/devices/1-3/power/wakeup allows the type cover to remain powered on during freeze, but it does not wake the system. It defaults to "disabled", which could be adjusted with a udev rule eventually.
(In reply to Stephen Just from comment #0) > On the Surface 3 tablet, I am unable to wake up a device that has been > frozen with "echo freeze > /sys/power/state" with any device other than the > capacitive "Windows" button or power button on the device. > this depends on the drivers. Any driver that wants to wakeup the system from freeze state should configure its wakeup IRQ properly. This is not controlled by ACPI. > Note: Support for the Windows button and other hardware keys requires patch > set from http://www.spinics.net/lists/linux-input/msg44595.html, so anyone > without this patch set has no way of unfreezing. > Also, https://bugzilla.kernel.org/show_bug.cgi?id=106941#c34 to keep the > system from repeatedly suspending, or disable lid switch suspend in > /etc/systemd/logind.conf > > In Windows, this device goes into a "connected standby" (i.e. low-power S0) > mode, and can be quickly woken with the Type Cover, or a USB attached mouse. > The Type Cover is just a USB device that goes through a hardware DRM > implementation. > > Note that the only device that appears in /proc/acpi/wakeup is "WIFI". > > I know very little about the power management stuff that happens in USB, but > I have some non-technical observations about freeze: > * When freeze happens, USB peripherals still have power - a connected USB > Hub still has an LED on. > * When freeze happens, a connected USB flash drive seems to suspend, its LED > goes off > * When freeze happens, the connected Type Cover seems to lose power - its > LEDs go off, and it does not respond to inputs. > * When freeze happens, moving a connected mouse seems to unsuspend the flash > drive, its LED comes back on, but the system does not wake up. (Does the USB > hub try to wake up everything attached to it?) > * Power button and Windows button will wake system. Hardware volume keys > will not. > > From my poor understanding of this system's DSDT, I think that the XHCI > controller is supposed to remain powered on, so things connected to it > shouldn't be suspending, which might make this an ACPI bug. Or a PM bug. Or > a bug in the USB stack. From the /proc/acpi/wakeup file attached, we can also see that there is no wakeup GPE for the xhci controller. This suggests it is a USB problem that does not configure its native wakeup interrupt properly.
On Tue, Jun 28, 2016 at 03:04:49AM +0000, bugzilla-daemon@bugzilla.kernel.org wrote: Please send to the linux-usb@vger.kernel.org mailing list.