Bug 11961 - TSC-10 DM USB touchscreen driver assume 2-byte response from controller
TSC-10 DM USB touchscreen driver assume 2-byte response from controller
Status: RESOLVED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Input Devices
All Linux
: P1 normal
Assigned To: drivers_input-devices
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-05 09:44 UTC by Nuno Lucas
Modified: 2009-04-08 12:43 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.25.19
Tree: Mainline
Regression: No


Attachments

Description Nuno Lucas 2008-11-05 09:44:56 UTC
Latest working kernel version: never
Earliest failing kernel version:
Distribution: kernel.org
Hardware Environment: x86
Software Environment:
Problem Description:

The usbtouchscreen module implements a driver for the TSC-10 DM USB touchscreen controllers, but assumes a 2-byte response for the CMD_RESET and CMD_RATE commands, when they can be only a single byte when no EEPROM is connected.

The following patch in the dmc_tsc10_init() function (which fixes the problem) should make it clear:

diff -urpN linux-2.6.25.19.orig/drivers/input/touchscreen/usbtouchscreen.c linux-2.6.25.19-patched/drivers/input/touchscreen/usbtouchscreen.c
--- linux-2.6.25.19.orig/drivers/input/touchscreen/usbtouchscreen.c     2008-10-22 22:19:25.000000000 +0100
+++ linux-2.6.25.19-patched/drivers/input/touchscreen/usbtouchscreen.c  2008-11-05 17:01:06.000000000 +0000
@@ -407,7 +407,8 @@ static int dmc_tsc10_init(struct usbtouc
                              0, 0, buf, 2, USB_CTRL_SET_TIMEOUT);
        if (ret < 0)
                return ret;
-       if (buf[0] != 0x06 || buf[1] != 0x00)
+       printk( "dmc_tsc10_init: RESET=>'%02X%02X\n'", buf[0], buf[1]  );
+       if (buf[0] != 0x06 /*|| buf[1] != 0x00*/)
                return -ENODEV;

        /* set coordinate output rate */
@@ -418,7 +419,8 @@ static int dmc_tsc10_init(struct usbtouc
                              TSC10_RATE_150, 0, buf, 2, USB_CTRL_SET_TIMEOUT);
        if (ret < 0)
                return ret;
-       if ((buf[0] != 0x06 || buf[1] != 0x00) &&
+       printk( "dmc_tsc10_init: RATE=>'%02X%02X\n'", buf[0], buf[1]  );
+       if ((buf[0] != 0x06 /*|| buf[1] != 0x00*/) &&
            (buf[0] != 0x15 || buf[1] != 0x01))
                return -ENODEV;

The driver worked with an earlier controller revision, but new revisions of the controller (now discontinued, but still on sale) fail.

It seems the problem is that the early controller had the SEL4/EEPROM-CS pin high, but the new controller has it down, making the response different.

Without the fix, the controller would answer the single byte 0x06 (ACK), making the init fail with -ENODEV because buf[1] is 0xFF (as initialized before).

As the single byte is the only thing we need to check it was ok, there is no need to verify the second byte.

The [0x15 0x01] case is the NAK [0x15] response for when there is no data in the EEPROM [bit-0 of second byte set], so I let that be, as I don't have any controller with an EEPROM.

With this patch, both the earlier and latest controller work the same.
Comment 1 Andrew Morton 2008-11-05 10:27:01 UTC
Please submit patches via email.  Documentation/SubmittingPatches
describes the process.  Suitable recipients for this patch are

linux-input@vger.kernel.org
linux-kernel@vger.kernel.org
Dmitry Torokhov <dtor@mail.ru>
Andrew Morton <akpm@linux-foundation.org>

Thanks.
Comment 2 Nuno Lucas 2008-11-06 07:32:41 UTC
Patch sent via email:
http://lkml.org/lkml/2008/11/6/222

Thanks.
Comment 3 Nuno Lucas 2009-04-08 12:43:28 UTC
I'm closing this as the patch was applied to 2.6.29.

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