Clearing stalls: usbd_xfer_set_stall vs
usbd_do_clear_stall_callback
Hans Petter Selasky
hselasky at c2i.net
Thu May 5 08:11:06 UTC 2011
On Thursday 05 May 2011 09:15:09 Trevor Blackwell wrote:
> 8.2-STABLE. I'm willing to run whatever.
>
> I suspect the problem I'm having is the same as this:
> http://kerneltrap.org/mailarchive/linux-usb/2009/5/15/5761363
>
> I can manually kick it out of the wedged state by sending a RESET_TT
> transaction to the hub with usbconfig -d ugen1.3 do_request 0x23 0x09
> 0x0000 0x0001 0
>
> (UT_WRITE_CLASS_OTHER, UR_RESET_TT)
>
> I'm working on adding code to do this. My current hack is to do it from
> uhub_explore. When my driver tries to do a clear-stall and gets a timeout
> error from the clear-stall, it sets a flag on the parent_hs_hub to request
> a RESET_TT. uhub_explore notices the flag and does it.
>
> Possibly I could also add it to usb_do_clear_stall_callback, but I don't
> think I can call usb_do_request from inside a callback.
>
> Any suggestions?
Hi,
I think it is best to do this from the root HUB thread, then the operation
gets properly serialised. Then the clear-stalls requests will simply be
pending until normal operation is established.
Could a control endpoint timeout in general imply that the parent High Speed
HUB, if any, should be reset?
--HPS
More information about the freebsd-usb
mailing list