On Thu, 1 Nov 2007, Steven King wrote:

quoted text
> > 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.
> 
> Okay, attached is full .config, dmesg, /proc/bus/usb/devices and lsusb for 
> 2.6.23.1 (aka working dongle), 2.6.24-rc1 (aka non-working dongle), 
> 2.6.24-rc1-r (2.6.24-rc1 with commit 063a2da8f01806906f7d7b1a1424b9afddebc443 
> backed out, aka working dongle 2) and finally 2.6.24-rc1-X (2.6.24-rc1 with 
> my patch to ti_usb_3410_5052, aka working dongle 3).  Normally I have a udev 
> rule to automagically select configuration 2, for these tests I disabled 
> that.  The {dmesg, proc.bus.usb.devices, lsusb}-2.6.xxx-1 is after I 
> did 'echo 2 > /sys/.../bConfigurationValue'.
> 
> Clean fresh build for each of the kernels, the dongle was plugged after the 
> system was fully up and X had started.

Okay, this explains everything.  In 2.6.23 (or 2.6.24-rc1 with the 
commit backed out), usb-serial binds to the "wrong" interface and 
performs a firmware download.  Up to that point the device has just the 
one configuration, but with the new firmware it has two.  Then you 
install the second config and the driver can bind successfully.

With 2.6.24-rc1, the driver never gets a chance to update the firmware 
because the invalid endpoint matching prevents it.

Oliver, what do you think should be done to solve this?

Alan Stern

-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/