On Fri, 4 Oct 2002, David Brownell wrote: > Matthew Dharm wrote: > > Hrm... > > > > Well, I can try this as an experiment... just assume that the clear halt > > has worked... tho the logs suggest that it didn't. > > I'm not sure I see what you're saying. I think the correct response > from device+core+hcds is quite typically going to be reporting -EPIPE > to drivers trying to clear a control halt. It indicates "there was no > control halt" ... not "the clear didn't work".
My feeling (in case anybody cares) is that we shouldn't try to clear stalls on the control endpoint. First of all, properly designed devices will only have protocol stalls, which don't need to be cleared. Secondly, if some device does have a functional stall then it's a nonstandard vendor-specific addition, which we shouldn't try to second-guess; the obvious thing to try instead is a bus reset. Getting -EPIPE when trying to clear a control halt has an unclear meaning. I suppose it might mean "there was no control halt", although perhaps it would be more correct to phrase this as "the control endpoint doesn't support the halt feature". (If the halt feature _is_ supported, then clearing a non-existent halt shouldn't generate any sort of error response; it should just be a no-op.) More likely meanings include "there is some sort of hardware failure" or "the firmware is wedged" or "something's wrong with the HCD" -- one of these last ones is probably what Matt is seeing. In any case, I don't see any proper way to deal with it apart from just giving up any resetting. Alan Stern ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
