On Wed, 1 Mar 2006 16:27:56 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
> 0:15.261198 # 10 S Ci 009:00 s 80 00 0000 0000 0002 ( DtH st dv GET_STATUS ) > --- 2 < > 0:15.261201 # 11 S Ci 009:00 s 80 06 0600 0000 000a ( DtH st dv > GET_DESCRIPTOR [DEVICE_QUALIFIER 0] ) --- 10 < > ... > 0:15.261981 # 10 C Ci 009:00 --- 0 2 = 0100 > 0:15.261982 # 10 S Ci 009:00 s 80 00 0000 0000 0002 ( DtH st dv GET_STATUS ) > --- 2 < > 0:15.261988 # 11 C Ci 009:00 --- -32 0 > > I interpret this to mean that the device is asking the host for the > device status and then a DEVICE_QUALIFIER descriptor. It returns > 0x0100. The device turns around and asks for it again. The host then > returns an error, -EPIPE, for that URB. Am I understanding this flow > correctly? Device cannot ask host anything in USB. It just sits there quietly and waits to be polled. Always. So, in the above exchange, host performs two control transfers. The log seems to be post-processed by some tool, which dropped interesting information such as URB tag. The numbers on the left may be manufactured from the tag. If so, it appears that the host - submits GET_STATUS - submits GET_DESCRIPTOR - receives status - submits another GET_STATUS - receives a stall for GET_DESCRIPTOR So, the control transfers are queued. Are you sure that it's a sane thing to do? -- Pete ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
