lkml.org 
[lkml]   [2014]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v3 3/4] input: alps: For protocol V3, do not process data when last packet's bit7 is set
Date
On Sunday 09 November 2014 21:34:59 Dmitry Torokhov wrote:
> On Sun, Nov 09, 2014 at 12:22:51PM +0100, Pali Rohár wrote:
> > On Sunday 09 November 2014 08:50:39 Dmitry Torokhov wrote:
> > > Hi Pali,
> > >
> > > On Sun, Nov 02, 2014 at 12:25:09AM +0100, Pali Rohár wrote:
> > > > 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 and drops it with PSMOUSE_FULL_PACKET
> > > > so psmouse driver does not enter to out of sync state.
> > > >
> > > > This patch fix problem when psmouse driver still
> > > > resetting ALPS device when laptop lid is closed because
> > > > of receiving invalid packets in out of sync state.
> > > >
> > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > > Tested-by: Pali Rohár <pali.rohar@gmail.com>
> > > > Cc: stable@vger.kernel.org
> > > > ---
> > > >
> > > > drivers/input/mouse/alps.c | 10 ++++++++++
> > > > 1 file changed, 10 insertions(+)
> > > >
> > > > diff --git a/drivers/input/mouse/alps.c
> > > > b/drivers/input/mouse/alps.c index 7c47e97..e802d28
> > > > 100644 --- a/drivers/input/mouse/alps.c
> > > > +++ b/drivers/input/mouse/alps.c
> > > > @@ -1181,6 +1181,16 @@ static psmouse_ret_t
> > > > alps_process_byte(struct psmouse *psmouse)
> > > >
> > > > return PSMOUSE_BAD_DATA;
> > > >
> > > > }
> > > >
> > > > + if (priv->proto_version == ALPS_PROTO_V3 &&
> > > > psmouse->pktcnt == psmouse->pktsize) { + // For
> > > > protocol V3, do not process data when last packet's
> > > > bit7 is set + if (psmouse->packet[psmouse->pktcnt -
1]
> > > > & 0x80) { + psmouse_dbg(psmouse, "v3 discard
> > > > packet[%i] =
> >
> > %x\n",
> >
> > > > + psmouse->pktcnt - 1,
> > > > + psmouse->packet[psmouse->pktcnt - 1]);
> > > > + return PSMOUSE_FULL_PACKET;
> > > > + }
> > > > + }
> > >
> > > I wanted to apply it, but I would like some more data.
> > > Could you please send me the dmesg with i8042.debug wit
> > > this patch in place?
> > >
> > > Thanks!
> >
> > See attachment. It contains debug log from both
> > i8042.debug=1 and psmouse.ko with applied all 4 patches.
>
> Thank you Pali.
>
> OK, so it looks like the problematic byte is the last one and
> we should be resynching right away. With your other patch
> increasing number of bad packets before issuing resync this
> special handling is no longer needed, right?
>
> Thanks.

Problem is that in this special case driver is still out-of-sync
and cause problems. E.g there is big dmesg flood and it is not
good to have that when LID is closed for a long time.

--
Pali Rohár
pali.rohar@gmail.com
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2014-11-10 11:01    [W:0.052 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site