Georg Acher wrote: ... >It looks like your case (stall in data phase) is treated as a short packet >with a manually executed status phase, which is wrong. The "stalled" state >is detected (and IMHO the endpoint state of the device-structure should >reflect this), but it doesn't survive in the end...
Interesting; I didn't look at the code (sorry, I was in a hurry). >I will fix it.. excellent! any idea what uhci.c does in this case? (it looks like it will return an error and not do the status phase, and usb-ohci.c looks the same) Interesting, if you fix this my audio box will stop working. It seems to respond to one of the control messages with a "protocol stall" (as opposed to a function stall). note that protocol stall = stall on control pipe. This seems to indication a function which is not implemented or does not work... I'm wondering if, in fact, it's ok/better/recommended to include the status phase for an 'protocol stall', but not a function stall... I'd be curious to hear what others think. I've had problems getting audio.c to work with different audio devices. Some of the behavior has been hci driver dependent (i.e. ohci != uhci != usb-uhci) on some of these finer points. Humm... maybe this is why usb-ohci worked better :-) -brad _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
