Eric Lee / smarc-ti-linux-kernel

5
Download as
Browse Code »

Commit a7ef82aee91f26da79b981b9f5bca43b8817d3e4

Authored by Pali Rohár
Committed by Dmitry Torokhov
1 parent 9d720b34c0
Exists in ti-lsk-linux-4.1.y and in 10 other branches dlt-processor-sdk-linux-03.00.00.04, processor-sdk-linux-02.00.01, smarc-ti-lsk-linux-4.1.y, smarct3x-processor-sdk-04.01.00.06, smarct3x-processor-sdk-linux-02.00.01, smarct3x-processor-sdk-linux-03.00.00.04, smarct4x-800-processor-sdk-linux-02.00.01, smarct4x-processor-sdk-04.01.00.06, smarct4x-processor-sdk-linux-02.00.01, smarct4x-processor-sdk-linux-03.00.00.04

Input: alps - ignore bad data on Dell Latitudes E6440 and E7440 

Sometimes on Dell Latitude laptops psmouse/alps driver receive invalid ALPS
protocol V3 packets with bit7 set in last byte. More often it can be
reproduced on Dell Latitude E6440 or E7440 with closed lid and pushing
cover above touchpad.

If bit7 in last packet byte is set then it is not valid ALPS packet. I was
told that ALPS devices never send these packets. It is not know yet who
send those packets, it could be Dell EC, bug in BIOS and also bug in
touchpad firmware...

With this patch alps driver does not process those invalid packets, but
instead of reporting PSMOUSE_BAD_DATA, getting into out of sync state,
getting back in sync with the next byte and spam dmesg we return
PSMOUSE_FULL_PACKET. If driver is truly out of sync we'll fail the checks
on the next byte and report PSMOUSE_BAD_DATA then.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Pali Rohár <pali.rohar@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Showing 1 changed file with 16 additions and 1 deletions Side-by-side Diff

drivers/input/mouse/alps.c
Diff comments   View file @ a7ef82a
... ... @@ -1186,12 +1186,27 @@
1186 1186 }
1187 1187  
1188 1188 /* Bytes 2 - pktsize should have 0 in the highest bit */
1189   - if ((priv->proto_version < ALPS_PROTO_V5) &&
  1189 + if (priv->proto_version < ALPS_PROTO_V5 &&
1190 1190 psmouse->pktcnt >= 2 && psmouse->pktcnt <= psmouse->pktsize &&
1191 1191 (psmouse->packet[psmouse->pktcnt - 1] & 0x80)) {
1192 1192 psmouse_dbg(psmouse, "refusing packet[%i] = %x\n",
1193 1193 psmouse->pktcnt - 1,
1194 1194 psmouse->packet[psmouse->pktcnt - 1]);
  1195 +
  1196 + if (priv->proto_version == ALPS_PROTO_V3 &&
  1197 + psmouse->pktcnt == psmouse->pktsize) {
  1198 + /*
  1199 + * Some Dell boxes, such as Latitude E6440 or E7440
  1200 + * with closed lid, quite often smash last byte of
  1201 + * otherwise valid packet with 0xff. Given that the
  1202 + * next packet is very likely to be valid let's
  1203 + * report PSMOUSE_FULL_PACKET but not process data,
  1204 + * rather than reporting PSMOUSE_BAD_DATA and
  1205 + * filling the logs.
  1206 + */
  1207 + return PSMOUSE_FULL_PACKET;
  1208 + }
  1209 +
1195 1210 return PSMOUSE_BAD_DATA;
1196 1211 }
1197 1212