My TI eZ430 (MSP-FET430UIF JTAG Tool) usb dongle works fine with 2.6.23.1
and earlier, but doesn't work with 2.6.24-rc1; the ti_usb_3410_5052 module is
loaded but the device descriptor is bogus, reporting only a single
configuration, whereas in 2.6.23.1 it reports 2 configurations, allowing one
to select the second configuration to get a serial port.
git bisect fingered this commit:
063a2da8f01806906f7d7b1a1424b9afddebc443 "USB: serial core should respect
driver requirements"
--
Steven King -- sfking at fdwdc dot com
On Wed, Oct 31, 2007 at 10:25:43PM -0700, Steven King wrote:
> My TI eZ430 (MSP-FET430UIF JTAG Tool) usb dongle works fine with 2.6.23.1
> and earlier, but doesn't work with 2.6.24-rc1; the ti_usb_3410_5052 module is
> loaded but the device descriptor is bogus, reporting only a single
> configuration, whereas in 2.6.23.1 it reports 2 configurations, allowing one
> to select the second configuration to get a serial port.
>
> git bisect fingered this commit:
>
> 063a2da8f01806906f7d7b1a1424b9afddebc443 "USB: serial core should respect
> driver requirements"
Can you send me a copy of /proc/bus/usb/devices with this device plugged
in?
thanks,
greg k-h
On Wednesday 31 October 2007 11:19:54 Greg KH wrote:
> On Wed, Oct 31, 2007 at 10:25:43PM -0700, Steven King wrote:
> > My TI eZ430 (MSP-FET430UIF JTAG Tool) usb dongle works fine with
> > 2.6.23.1 and earlier, but doesn't work with 2.6.24-rc1; the
> > ti_usb_3410_5052 module is loaded but the device descriptor is bogus,
> > reporting only a single configuration, whereas in 2.6.23.1 it reports 2
> > configurations, allowing one to select the second configuration to get a
> > serial port.
> >
> > git bisect fingered this commit:
> >
> > 063a2da8f01806906f7d7b1a1424b9afddebc443 "USB: serial core should respect
> > driver requirements"
>
> Can you send me a copy of /proc/bus/usb/devices with this device plugged
> in?
Sure,
for 2.6.23.1:
T: Bus=07 Lev=02 Prnt=02 Port=03 Cnt=01 Dev#= 18 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=ff(vend.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 2
P: Vendor=0451 ProdID=f430 Rev= 1.01
S: Manufacturer=Texas Instruments
S: Product=MSP-FET430UIF JTAG Tool
S: SerialNumber=TUSB341010398282E658FFD7
C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=
E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
C:* #Ifs= 1 Cfg#= 2 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=ti_usb_3410_5052
E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=83(I) Atr=03(Int.) MxPS= 2 Ivl=1ms
and 2.6.24-rc1:
T: Bus=07 Lev=02 Prnt=13 Port=03 Cnt=01 Dev#= 14 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=ff(vend.) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0451 ProdID=f430 Rev= 1.01
S: Manufacturer=Texas Instruments
S: Product=MSP-FET430UIF JTAG Tool
S: SerialNumber=TUSB341010398282E658FFD7
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
full /proc/bus/usb/devices for both versions are attached
--
Steven King -- sfking at fdwdc dot com
Per a suggestion by David Brownwell, rebuilt with CONFIG_USB_DEBUG enabled and
loading usbserial and ti_usb_3410_5052 with debug=1, I see in 'dmesg'
'drivers/usb/serial/usb-serial.c: wrong number of endpoints'
which is pretty much what I expected, throwing some more printk's in
usb-serial gives:
drivers/usb/serial/usb-serial.c: num_interrupt_in = 0, expected 1
drivers/usb/serial/usb-serial.c: num_interrupt_out = 0, expected 0
drivers/usb/serial/usb-serial.c: num_bulk_in = 0, expected 1
drivers/usb/serial/usb-serial.c: num_bulk_out = 1, expected 1
Okay, so
---
Changing num_interrupt_in and num_bulk_in from 1 to NUM_DONT_CARE makes
ti_usb_3410_5052 work again, but is it the right thing to do?
Signed-off-by: Steven King <[email protected]>
---
ti_usb_3410_5052.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/serial/ti_usb_3410_5052.c
b/drivers/usb/serial/ti_usb_3410_5052.c
index 1f01494..337f5ce 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.c
+++ b/drivers/usb/serial/ti_usb_3410_5052.c
@@ -264,8 +264,8 @@ static struct usb_serial_driver ti_1port_device = {
.description = "TI USB 3410 1 port adapter",
.usb_driver = &ti_usb_driver,
.id_table = ti_id_table_3410,
- .num_interrupt_in = 1,
- .num_bulk_in = 1,
+ .num_interrupt_in = NUM_DONT_CARE,
+ .num_bulk_in = NUM_DONT_CARE,
.num_bulk_out = 1,
.num_ports = 1,
.attach = ti_startup,
On Wed, 31 Oct 2007, Steven King wrote:
> My TI eZ430 (MSP-FET430UIF JTAG Tool) usb dongle works fine with 2.6.23.1
> and earlier, but doesn't work with 2.6.24-rc1; the ti_usb_3410_5052 module is
> loaded but the device descriptor is bogus, reporting only a single
> configuration, whereas in 2.6.23.1 it reports 2 configurations, allowing one
> to select the second configuration to get a serial port.
>
> git bisect fingered this commit:
>
> 063a2da8f01806906f7d7b1a1424b9afddebc443 "USB: serial core should respect
> driver requirements"
Are you certain about this? That commit could not possibly have
changed the way the USB core evaluates the device or configuration
descriptors. In fact, the commit affects only code in the usb-serial
driver, which doesn't get loaded until well after the descriptors have
been parsed.
Alan Stern
On Thu, 1 Nov 2007, Steven King wrote:
> Per a suggestion by David Brownwell, rebuilt with CONFIG_USB_DEBUG enabled and
> loading usbserial and ti_usb_3410_5052 with debug=1, I see in 'dmesg'
>
> 'drivers/usb/serial/usb-serial.c: wrong number of endpoints'
>
> which is pretty much what I expected, throwing some more printk's in
> usb-serial gives:
>
> drivers/usb/serial/usb-serial.c: num_interrupt_in = 0, expected 1
> drivers/usb/serial/usb-serial.c: num_interrupt_out = 0, expected 0
> drivers/usb/serial/usb-serial.c: num_bulk_in = 0, expected 1
> drivers/usb/serial/usb-serial.c: num_bulk_out = 1, expected 1
>
> Okay, so
> ---
>
> Changing num_interrupt_in and num_bulk_in from 1 to NUM_DONT_CARE makes
> ti_usb_3410_5052 work again, but is it the right thing to do?
It may or may not be the right thing to do, but it definitely isn't
the correct way to solve your problem.
The real question is why 2.6.24-rc1 doesn't like the second
configuration descriptor. To answer it, you should see what shows up
in the dmesg log when you first plug in the device on a kernel with
CONFIG_USB_DEBUG enabled.
Alan Stern
On Thursday 01 November 2007 7:47:24 Alan Stern wrote:
> On Wed, 31 Oct 2007, Steven King wrote:
> > My TI eZ430 (MSP-FET430UIF JTAG Tool) usb dongle works fine with
> > 2.6.23.1 and earlier, but doesn't work with 2.6.24-rc1; the
> > ti_usb_3410_5052 module is loaded but the device descriptor is bogus,
> > reporting only a single configuration, whereas in 2.6.23.1 it reports 2
> > configurations, allowing one to select the second configuration to get a
> > serial port.
> >
> > git bisect fingered this commit:
> >
> > 063a2da8f01806906f7d7b1a1424b9afddebc443 "USB: serial core should respect
> > driver requirements"
>
> Are you certain about this? That commit could not possibly have
> changed the way the USB core evaluates the device or configuration
> descriptors. In fact, the commit affects only code in the usb-serial
> driver, which doesn't get loaded until well after the descriptors have
> been parsed.
100% certain. After bisecting it, I reversed that commit on an otherwise
stock -rc1 and the device started working again.
--
Steven King -- sfking at fdwdc dot com
On Thursday 01 November 2007 7:51:25 Alan Stern wrote:
> On Thu, 1 Nov 2007, Steven King wrote:
> > Per a suggestion by David Brownwell, rebuilt with CONFIG_USB_DEBUG
> > enabled and loading usbserial and ti_usb_3410_5052 with debug=1, I see in
> > 'dmesg'
> >
> > 'drivers/usb/serial/usb-serial.c: wrong number of endpoints'
> >
> > which is pretty much what I expected, throwing some more printk's in
> > usb-serial gives:
> >
> > drivers/usb/serial/usb-serial.c: num_interrupt_in = 0, expected 1
> > drivers/usb/serial/usb-serial.c: num_interrupt_out = 0, expected 0
> > drivers/usb/serial/usb-serial.c: num_bulk_in = 0, expected 1
> > drivers/usb/serial/usb-serial.c: num_bulk_out = 1, expected 1
> >
> > Okay, so
> > ---
> >
> > Changing num_interrupt_in and num_bulk_in from 1 to NUM_DONT_CARE makes
> > ti_usb_3410_5052 work again, but is it the right thing to do?
>
> It may or may not be the right thing to do, but it definitely isn't
> the correct way to solve your problem.
>
> The real question is why 2.6.24-rc1 doesn't like the second
> configuration descriptor. To answer it, you should see what shows up
> in the dmesg log when you first plug in the device on a kernel with
> CONFIG_USB_DEBUG enabled.
?!? As I wrote at the top of the message you quoted, I rebuilt with
CONFIG_USB_DEBUG enabled and loaded the modules with debug=1, thats how I was
able to see the 'wrong number of endpoints' message.
Given that the dongle works correctly with a stock 2.6.24-rc1 with commit
063a2da8f01806906f7d7b1a1424b9afddebc443 reversed, I'm reasonably confident
that with that commit in place, the usb core is working correctly (or atleast
as expected) in initially parsing the device descriptor, then usb-serial
attempts to match the interface descriptor on the first configuration, and
using the new more strict matching code, fails when the device reports for
the only interface on the first configuration it has only a single bulk_out
endpoint while the ti_usb_3410_5052 driver is expecting an interrupt_in and a
bulk_in. It never gets to the second configuration descriptor.
#2.6.23.1 lsusb -vvv:
Bus 007 Device 005: ID 0451:f430 Texas Instruments, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0451 Texas Instruments, Inc.
idProduct 0xf430
bcdDevice 1.01
iManufacturer 1 Texas Instruments
iProduct 2 MSP-FET430UIF JTAG Tool
iSerial 3 TUSB341010398282E658FFD7
bNumConfigurations 2
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 2
iConfiguration 0
bmAttributes 0xa0
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 1
#2.6.24-rc1 lsusb -vvv
Bus 007 Device 004: ID 0451:f430 Texas Instruments, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0451 Texas Instruments, Inc.
idProduct 0xf430
bcdDevice 1.01
iManufacturer 1 Texas Instruments
iProduct 2 MSP-FET430UIF JTAG Tool
iSerial 3 TUSB341010398282E658FFD7
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
for me the only question is whether ti_usb_3410_5052 should
have .num_interrupt_in and .num_bulk_in set to NUM_DONT_CARE or set to 0.
Are there versions of the dongle that have different device descriptors?
Before I bricked (sticked?) my TI eZ430-rf2500 dongle, it reported a
different idProduct even though as far as I can tell they are almost the
exact same hardware, so that shouldnt be a problem...
--
Steven King -- sfking at fdwdc dot com
On Thu, 1 Nov 2007, Steven King wrote:
> > The real question is why 2.6.24-rc1 doesn't like the second
> > configuration descriptor. To answer it, you should see what shows up
> > in the dmesg log when you first plug in the device on a kernel with
> > CONFIG_USB_DEBUG enabled.
>
> ?!? As I wrote at the top of the message you quoted, I rebuilt with
> CONFIG_USB_DEBUG enabled and loaded the modules with debug=1, thats how I was
> able to see the 'wrong number of endpoints' message.
But you didn't post the log messages, so I haven't seen them.
In addition, that "wrong number of endpoints" message occurs long after
the underlying problem; it's probably not connected.
> Given that the dongle works correctly with a stock 2.6.24-rc1 with commit
> 063a2da8f01806906f7d7b1a1424b9afddebc443 reversed,
Can you post the /proc/bus/usb/devices entry under that kernel? Do
both configurations show up?
> I'm reasonably confident
> that with that commit in place, the usb core is working correctly (or atleast
> as expected) in initially parsing the device descriptor, then usb-serial
> attempts to match the interface descriptor on the first configuration, and
> using the new more strict matching code, fails when the device reports for
> the only interface on the first configuration it has only a single bulk_out
> endpoint while the ti_usb_3410_5052 driver is expecting an interrupt_in and a
> bulk_in. It never gets to the second configuration descriptor.
Why shouldn't the core ever get to parse the second configuration
descriptor? Config descriptor parsing happens before driver matching
and binding. It has to; otherwise the core wouldn't know which
configuration to install by default.
In the "working" 2.6.23 kernel there were two configurations and Config
#2 was installed. What happens if you install Config #1 under that
kernel (echo 1 >/sys/bus/usb/devices/.../bConfigurationValue)?
Presumably if Config #2 was present and installed in the "non-working"
2.6.24-rc1 kernel, the driver would bind correctly.
> for me the only question is whether ti_usb_3410_5052 should
> have .num_interrupt_in and .num_bulk_in set to NUM_DONT_CARE or set to 0.
Then you're concerned about the wrong question. It's more important to
find out why Config #2 disappeared under 2.6.24-rc1. The commit you
are focused on would not have caused it.
> Are there versions of the dongle that have different device descriptors?
> Before I bricked (sticked?) my TI eZ430-rf2500 dongle, it reported a
> different idProduct even though as far as I can tell they are almost the
> exact same hardware, so that shouldnt be a problem...
I have no idea what versions of your dongle are available. In fact, I
never heard of it before reading your email messages. However if you
have had two different dongles that report different idProduct values,
it's a safe bet that _something_ has changed between them. The
firmware, if nothing else.
Alan Stern