Alan Stern wrote:
Xiaofan was suggesting that your workaround might not be needed with
later kernels. But keeping the workaround shouldn't hurt anything.
Hi,
Yes, but I don't understand the logic that this has anything
to do with my problems. Why would the Linux USB driver be
putting a Set-Interface between each data read ?
[I presume this is not the case.]
ie. if on recent Linux kernels the resetep IOCTL no longer does anything
(ie. it doesn't reset the data toggle), then it breaks my workaround.
No. The premise and the conclusion in that sentence are both false.
Which is what I expected, but wanted confirmed. If that is not
the connection between set-interface and data reads having
(presumed) data toggle issues, what is ?
It does figure into your problem, because earlier Linux kernels would
automatically send a Set-Interface request whenever a program released
an interface. If the device doesn't handle these requests properly,
the data toggles can get messed up.
The interface doesn't get released. To be completely clear the software:
Opens the device
Configures the device
Resets the data read end point.
Does numerous control transactions
Does control transaction to create read data
Does a data read from the read end point that times out.
Whereas if it:
Opens the device
Configures the device
Does numerous control transactions
Does control transaction to create read data
Resets the data read end point.
Does a data read from the read end point OK
Does control transaction to create read data
Resets the data read end point.
Does a data read from the read end point OK
etc.
If I place a secondary hub between the computer and the device,
its behaviour is:
Opens the device
Configures the device
Resets the data read end point.
Does numerous control transactions
Does control transaction to create read data
Resets the data read end point.
Does a data read from the read end point that times out.
But only with modern kernels. For 2.6.9-55 the last case works.
More recent kernels do not automatically send the Set-Interface
request, providing the interface was already in altsetting 0 when it
was released.
These sound like configuration & open/close issues. I don't have any issues
with opening or doing control I/O to the device. It seems as if control operations
set the data toggle to the wrong state for the data read, and therefore
data reads need a resetep to fix it before each read. Yes, this is
probably some sort of firmware problem in the device, but as I said,
it's interesting that MSWin and OS X don't have this problem.
I (and my end users) wouldn't care about that if the secondary
hub case worked, since the resetep workaround is sufficient.
Thanks,
Graeme Gill.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
