[PATCH] input: Force Sentelic reconnect when mode setting has failed

The Sentelic touchpad in an Asus UX-21 failed to work since the native
driver was merged. Examination showed that the FSP_REG_SWC1 register had
reverted back to 0x80 and so the pad was sending normal packets despite
the driver expecting absolute ones.

I haven't been able to identify what causes this - dumping the register
state after ps2 setup shows it set correctly. The easiest workaround seems
to be to force a reconnect when an unexpected packet type is received.

Signed-off-by: Matthew Garrett <redacted>
---
 drivers/input/mouse/sentelic.c |   14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/input/mouse/sentelic.c b/drivers/input/mouse/sentelic.c
index 661a0ca..aaabf94 100644
--- a/drivers/input/mouse/sentelic.c
+++ b/drivers/input/mouse/sentelic.c

@@ -687,7 +687,7 @@ static psmouse_ret_t fsp_process_byte(struct psmouse *psmouse)
 	unsigned char *packet = psmouse->packet;
 	unsigned char button_status = 0, lscroll = 0, rscroll = 0;
 	unsigned short abs_x, abs_y, fgrs = 0;
-	int rel_x, rel_y;
+	int rel_x, rel_y, packet_type;
 
 	if (psmouse->pktcnt < 4)
 		return PSMOUSE_GOOD_DATA;

@@ -698,7 +698,17 @@ static psmouse_ret_t fsp_process_byte(struct psmouse *psmouse)
 
 	fsp_packet_debug(psmouse, packet);
 
-	switch (psmouse->packet[0] >> FSP_PKT_TYPE_SHIFT) {
+	packet_type = psmouse->packet[0] >> FSP_PKT_TYPE_SHIFT;
+
+	if (ad->ver >= FSP_VER_STL3888_C0 && packet_type != FSP_PKT_TYPE_ABS) {
+		psmouse_warn(psmouse,
+			     "Incorrect packet type %x, reconnecting\n",
+			     packet_type);
+		serio_reconnect(psmouse->ps2dev.serio);
+		return PSMOUSE_FULL_PACKET;
+	}
+
+	switch (packet_type) {
 	case FSP_PKT_TYPE_ABS:
 		abs_x = GET_ABS_X(packet);
 		abs_y = GET_ABS_Y(packet);

-- 
1.7.9.5

On Sat, 19 May 2012, Matthew Garrett wrote:

The Sentelic touchpad in an Asus UX-21 failed to work since the native
driver was merged. Examination showed that the FSP_REG_SWC1 register had
reverted back to 0x80 and so the pad was sending normal packets despite
the driver expecting absolute ones.

    Sounds to me that the hardware was reset, which usually happens if
there's intermittent power failure events.  Is there any particular step
to reproduce this unexpected resetting?

On Mon, May 21, 2012 at 11:22:07PM +0800, Tai-hwa Liang wrote:

On Sat, 19 May 2012, Matthew Garrett wrote:

quoted

The Sentelic touchpad in an Asus UX-21 failed to work since the native
driver was merged. Examination showed that the FSP_REG_SWC1 register had
reverted back to 0x80 and so the pad was sending normal packets despite
the driver expecting absolute ones.

   Sounds to me that the hardware was reset, which usually happens if
there's intermittent power failure events.  Is there any particular step
to reproduce this unexpected resetting?

None that I've identified. It only seems to do it once, and afterwards 
it's fine. I agree that this seems to be covering up some more insidious 
bug, but I spent most of Friday and Saturday failing to find one.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

On Mon, 21 May 2012, Matthew Garrett wrote:

On Mon, May 21, 2012 at 11:22:07PM +0800, Tai-hwa Liang wrote:

quoted

On Sat, 19 May 2012, Matthew Garrett wrote:

quoted

The Sentelic touchpad in an Asus UX-21 failed to work since the native
driver was merged. Examination showed that the FSP_REG_SWC1 register had
reverted back to 0x80 and so the pad was sending normal packets despite
the driver expecting absolute ones.

   Sounds to me that the hardware was reset, which usually happens if
there's intermittent power failure events.  Is there any particular step
to reproduce this unexpected resetting?

None that I've identified. It only seems to do it once, and afterwards
it's fine. I agree that this seems to be covering up some more insidious
bug, but I spent most of Friday and Saturday failing to find one.

Hi Matthew,

   Would you please run the attached script and post the result next time
when you run into the abnormal scenario(FSP sends normal instead of abs.
packets)?

   You probably need to do this experiment without the reconnecting patch
applied.

Thank you,

Tai-hwa Liang

When working: 0700, 4005, 4180, 4237
When broken : 0700, 4005, 4180, 4237

-- 
Matthew Garrett | mjg59@srcf.ucam.org

On Tue, 22 May 2012, Matthew Garrett wrote:

When working: 0700, 4005, 4180, 4237
When broken : 0700, 4005, 4180, 4237

   There's no hardware reset according to this dump.

   Now I'm confused: the hardware default of FSP_REG_SWC1 is zero and
there's no single piece of code(dirver/firmware) that will set SWC1 to
0x80 as far as I can remember.