Bug 196957

Summary:	Suspend to idle does not work after reattaching detachable keyboard on thinkpad helix 2
Product:	Drivers	Reporter:	Tudor Protopopescu (tprotopopescu)
Component:	Input Devices	Assignee:	drivers_input-devices
Status:	NEW ---
Severity:	normal	CC:	dmitry.torokhov, rui.zhang, russianneuromancer
Priority:	P1
Hardware:	Intel
OS:	Linux
Kernel Version:	4.13.1	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	dmesg output: boot with keyboard attached, detached, reattached and STI initiated dmesg output: boot without keyboard attached, initiate STI, resume dmesg output: boot with keyboard attached, initiate STI, resume

Description Tudor Protopopescu 2017-09-16 08:53:48 UTC

Created attachment 258423 [details]
dmesg output: boot with keyboard attached, detached, reattached and STI initiated

On the thinkpad helix 2 with the ultrabook pro keyboard dock suspend-to-idle/freeze does not work if the keyboard dock is detached and reattached while the device is on. After issuing `echo freeze > /sys/power/state' the device resumes immediately with error output `bash: echo: write error: No such device or address'.

In almost all circumstances STI/freeze works: 
* If the keyboard is never detached STI works. 
* If the device is booted without the keyboard STI works.
* If the device is booted with keyboard attached, the keyboard is detached (but not reattached) STI works until the keyboard is reattached, and fails after. This includes if the keyboard is detached while the device is frozen.

I've attached dmesg output for the following: 1) Boot with keyboard, initiate STI, resume; 2) boot with keyboard, detach, reattach, initiate STI, which fails; 3) boot without keyboard, initiate STI, resume.

Suspend to RAM is not supported by this platform any longer: `/sys/power/mem_sleep' has only [s2idle]. Using latest BIOS version, 1.93.

This bug is related to https://bugzilla.kernel.org/show_bug.cgi?id=100171.
Note that previous to kernel 4.13.1 the device could not be resumed from STI by the power button, only with keyboard input if the keyboard had never been detached.

This bug may be related to https://bugzilla.kernel.org/show_bug.cgi?id=196953.

Comment 1 Tudor Protopopescu 2017-09-16 08:58:05 UTC

Created attachment 258425 [details]
dmesg output: boot without keyboard attached, initiate STI, resume

Comment 2 Tudor Protopopescu 2017-09-16 08:59:43 UTC

Created attachment 258427 [details]
dmesg output: boot with keyboard attached, initiate STI, resume

Comment 3 Tudor Protopopescu 2017-09-28 07:11:35 UTC

I am not sure if this belongs here, or should be reported as a separate bug.

With 4.13.3 I notice that STI logs you out of your desktop session after about 10 minutes. If STI is invoked and the computer resumed immediately it resumes where you left off. If you wait about 10 minutes to resume the computer resumes at the desktop login.

Comment 4 Zhang Rui 2017-10-11 03:26:54 UTC

[  327.587036] rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-6).
[  327.588386] psmouse serio3: Failed to disable mouse on synaptics-rmi4-pt/serio1
[  327.589907] rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-6).
[  327.591525] call 1-3.4+ returned 0 after 20849 usecs
[  327.591558] rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-6).
[  327.591559] call serio3+ returned 0 after 4750 usecs
[  327.591562] calling  7-002c+ @ 3274, parent: i2c-7
[  327.591921] rmi4_f01 rmi4-00.fn01: Failed to write sleep mode: -6.
[  327.591921] rmi4_f01 rmi4-00.fn01: Suspend failed with code -6.
[  327.591922] rmi4_physical rmi4-00: Failed to suspend functions: -6
[  327.591924] rmi4_smbus 7-002c: Failed to suspend device: -6
[  327.591928] dpm_run_callback(): rmi_smb_suspend+0x0/0x50 [rmi_smbus] returns -6
[  327.591928] call 7-002c+ returned -6 after 356 usecs
[  327.591929] PM: Device 7-002c failed to suspend: error -6
[  327.711513] call 2-3+ returned 0 after 138003 usecs
[  327.713511] PM: Some devices failed to suspend, or early wake event detected

So the suspend-to-idle failure is caused by the device suspend failure.
Assign to the driver owner.

Comment 5 Dmitry Torokhov 2017-10-12 18:28:22 UTC

Cute. I2C bus is not hot [un]pluggable to the best of my knowledge.