Bug 1079862 - with kernel 4.15.0 touchpad is dead after resume
with kernel 4.15.0 touchpad is dead after resume
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Other Other
: P5 - None : Major (vote)
: ---
Assigned To: E-mail List
E-mail List
Depends on:
  Show dependency treegraph
Reported: 2018-02-07 15:02 UTC by Peter Sütterlin
Modified: 2018-03-25 11:02 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

journalctl -b of suspend/resume with timestamping (39.82 KB, application/x-xz)
2018-02-12 11:46 UTC, Peter Sütterlin
dmesg (410.12 KB, text/plain)
2018-02-13 08:20 UTC, Jiri Slaby

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Sütterlin 2018-02-07 15:02:27 UTC
After update to 4.15.0, the touchpad of my Lenovo T460p is only working after initial boot.  If I suspend/resume it falls dead.

The previous kernel (4.14.15) had used psmouse only,
 kernel: psmouse serio1: synaptics: Touchpad model: 1, fw: 8.2, id: 0x1e2b1, caps: 0xf006a3/0x943300/0x12e800/
0x10000, board id: 3053,fw id: 2010421
 kernel: psmouse serio1: synaptics: serio: Synaptics pass-through port at isa0060/serio1/input0

whereas 4.15.0 also lists

 kernel: input: Synaptics TM3053-006 as /devices/rmi4-00/input/input23

(rmi is not used/mentioned when running 4.14.15)

During resume I then get the following:

 kernel: rmi4_smbus 8-002c: failed to get SMBus version number!
 kernel: rmi4_physical rmi4-00: rmi_driver_reset_handler: Failed to read current IRQ mask.
 kernel: rmi4_f01 rmi4-00.fn01: Failed to restore normal operation: -16.
 kernel: rmi4_f01 rmi4-00.fn01: Resume failed with code -16.
 kernel: rmi4_physical rmi4-00: Failed to suspend functions: -16
 kernel: rmi4_smbus 8-002c: Failed to resume device: -16
 kernel: rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-16).

I found a very similar issue there:
(but that should be included by now?)

I had tried blacklisting rmi_smbus and rmi_core, but then the touchpad doesn't work at all, even in initial boot.
PS: the trackpoint suffers the same issue.
Comment 1 Jiri Slaby 2018-02-07 17:30:01 UTC
The only commit between 4.14 and 4.15 for rmi is this:
commit ef14a4bf0910d06c7e202552914028d4956809cb
Author: Andrew Duggan <aduggan@synaptics.com>
Date:   Tue Oct 17 18:37:36 2017 -0700

    HID: rmi: Check that a device is a RMI device before calling RMI functions

And it doesn't look related. Currently, I don't see a way how this could not be handled in 4.14 by rmi and in 4.15 it is.
Comment 2 Peter Sütterlin 2018-02-08 08:38:36 UTC
No, as I wrote, in 4.14.15, rmi is not used at all (for whatever reason).  The touchpad is used via the psmouse driver, and that works.

Maybe some default priority has changed and now rmi is enforced?

I'll see if I can use psmouse.synaptics_intertouch to force usage of rmi in 4.14.15 (or usage of psmouse in 4.15?)
Comment 3 Peter Sütterlin 2018-02-08 09:43:04 UTC
OK, indeed using psmouse.synaptics_intertouch=1 with the 4.14.15 kernel produces the same problem:  Touchpad is dead after a resume.  

So it's not 4.15 specific other than that in this version the parameter seems to default to 1, enforcing the (non-working) rmi driver.

I assume booting 4.15 with psmouse.synaptics_intertouch=0 should switch it to using the old psmouse driver (not tested yet).

But it's obvious that this touchpad doesn't go well with rmi4/smbus...
Comment 4 Jiri Slaby 2018-02-08 09:58:03 UTC
Oh, sure, T460p was indeed added to have psmouse.synaptics_intertouch=1 in 4.15:
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -173,6 +173,7 @@ static const char * const smbus_pnp_ids[] = {
        "LEN0046", /* X250 */
        "LEN004a", /* W541 */
        "LEN200f", /* T450s */
+       "LEN2018", /* T460p */
Comment 5 Peter Sütterlin 2018-02-08 10:54:11 UTC
Ok, clears things up :)

I just verified that indeed I can use psmouse.synaptics_intertouch=0 to switch back to the old psmouse version.  So I can circumvent the issue

I had (also) reported the issue to the linux-input mailing list.  Should I send a bugreport somewhere else, too?
Comment 6 Jiri Slaby 2018-02-12 08:00:24 UTC
Hmm, maybe the seuence between psmouse and rmi/smbus is not quite right
on resume on that box. Can you ask the reporter to:

echo 1 > /sys/power/pm_print_times

and send dmesg?
Comment 7 Peter Sütterlin 2018-02-12 11:46:00 UTC
Created attachment 759783 [details]
journalctl -b of suspend/resume with timestamping
Comment 8 Jiri Slaby 2018-02-13 08:20:24 UTC
Created attachment 759933 [details]
Comment 9 Jiri Slaby 2018-03-25 11:02:21 UTC
4.15.10 reverted the commit, so everything should be fine now.