Just to be clear:
- usb_unlink_urb() doesn't care any more about that state. (There seemed to be agreement that it must not matter.)
There is agreement, yes. But right now the host controllers can't handle this check not being there. I've put it back in, with a big FIXME comment.
You mean just UHCI host controllers, right? I certainly didn't see this when I tested against OHCI or EHCI. (And for that matter I have a hard time understanding how UHCI could care.)
I oopsed both uhci-hcd and ohci-hcd without that change. I don't have a usb-serial device that talks USB 2.0 to try that controller driver too :)
With those symptoms I have to say it sounds more like a usb-serial issue than anything else. What does the OHCI backtrace look like?
As for EHCI, you should be able to connect through a USB 2.0 hub:
EHCI root hub --> USB 2.0 hub --> serial device
That'll make the full/low speed traffic go through the transaction translator and use ehci-hcd, not the companion controller's driver.
In fact you really _should_ do that kind of testing, since the TT makes disconnect faults get reported slightly differently than either OHCI or UHCI hardware. Some drivers have needed patches to handle the faults returned before disconnect() can be called.
- Dave
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
