Bug 15780 - touchpad doesn't reconnect after resume: Synaptics ps2
Summary: touchpad doesn't reconnect after resume: Synaptics ps2
Status: RESOLVED OBSOLETE
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: All Linux
: P1 high
Assignee: drivers_input-devices
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-13 21:14 UTC by Peter M. Petrakis
Modified: 2012-07-11 15:13 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.31
Subsystem:
Regression: No
Bisected commit-id:


Attachments
psmouse probe reset port on failure before retry (1.15 KB, patch)
2010-04-13 21:14 UTC, Peter M. Petrakis
Details | Diff

Description Peter M. Petrakis 2010-04-13 21:14:30 UTC
Created attachment 25997 [details]
psmouse probe reset port on failure before retry

Working on an upcoming Dell laptop whose touchpad works fine on boot, but after coming back from S3, the system doesn't detect that a touchpad is present.

The attached patch perfoms a psmouse_reset on the port should the initial probe fail. I only need one reset to recover the Synaptic touchpad, the initial patch retries up to 3 times.

Background:

The kernel psmouse driver was instrumented and later the libps2 core and found we were bailing in psmouse_probe with -ENODEV.

[ 2241.043143] XXX loading psmouse module
[ 2241.043321] XXX finished loading psmouse [0]
[ 2241.043614] XXX (psmouse_connect) ENTER
[ 2241.043622] XXX (psmouse_probe) ENTER:879
[ 2241.043626] XXX (psmouse_probe) HERE [/root/build/linux-2.6.31/drivers/input/mouse/psmouse-base.c:887]
[ 2241.240721] XXX (psmouse_connect) psmouse probe failed ENODEV

        printk(KERN_INFO "XXX (%s) HERE [%s:%d] \n", __FUNCTION__, __FILE__, __LINE__);

        param[0] = 0xa5;
        if (ps2_command(ps2dev, param, PSMOUSE_CMD_GETID))
                return -1;

and...

Here's what's going on in libps2 during the failed probe which results in -ENODEV

     0 kseriod(41): -> ps2_init
ps2_init args [ps2dev=0xf006de08 serio=0xf6d36200 ]
exit 17 kseriod(41): -> ps2_init
ps2_init args []
     0 kseriod(41): -> ps2_command
ps2_command args [ps2dev=0xf006de08 param=0xf75bbeaa command=0x2f2 ]
(ps2_command) libps2.c:172
(ps2_command) libps2.c:177
(ps2_command) libps2.c:182
(ps2_command) libps2.c:197
    42 kseriod(41): -> ps2_sendbyte
ps2_sendbyte args [ps2dev=0xf006de08 byte=0xf2 timeout=0xc8 ]
exit 200048 kseriod(41): -> ps2_sendbyte
ps2_sendbyte args [return=0xffffffffffffffff ]
(ps2_command) libps2.c:224
exit 200070 kseriod(41): -> ps2_command
ps2_command args [return=0xffffffffffffffff ]

Generated by systemtap
...
probe kernel.function("ps2_*").call {
        printf ("%s -> %s\n", thread_indent(1), probefunc())
        printf ("%s args [%s]\n", probefunc(), $$parms)
}

probe kernel.function("ps2_*").return {
        printf ("exit %s -> %s\n", thread_indent(-1), probefunc())
        printf ("%s args [%s]\n", probefunc(), $$return)
}

So I noticed that while we have some elaborate reset code once we know what
kind of ps2 device we have, the probe routine itself by comparison doesn't try
as hard.

Note You need to log in before you can comment on or make changes to this bug.