Hi, Muni Sekhar <munisekharrms@xxxxxxxxx> writes: >>>>> #define USB_CTRL_GET_TIMEOUT 5000 >>>>> >>>>> #define USB_CTRL_SET_TIMEOUT 5000 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Does the above mentioned timeouts will vary based on the packet length >>>>> of control transfers (8, 16, 32 or 64 bytes)? >>>>> >>>>> >>>>> >>>>> I do have a USB Bluetooth device and it exposes the control endpoint >>>>> for sending HCI commands. >>>>> >>>>> >>>>> >>>>> I’m not sure what will be the good value for the >>>>> usb_control_msg()timeout for sending HCI commands, will it be safe to >>>>> use USB_CTRL_SET_TIMEOUT? >>>> >>>> why wouldn't it? If your device doesn't respond to a control message in >>>> 5 seconds, then you should really get that FW fixed or change your >>>> device to something that works. 5 seconds to transfer a few bytes is a >>>> really long time. Even for low-speed pipes (1.5Mbps), you can transfer >>>> 960 kiB in 5 seconds if you saturate the bus. How big are your HCI >>>> commands? >>> >>> HCI Command Packets with up to maximum of 255 bytes of data. >> >> then 5s is more than enough for you ;-) > > What usually triggers the usb_control_msg() call to return? Is it just > an acknowledgement from the device that the command has been received? No, it's completion of the entire thing. A control message is 2 or 3 phases. It goes like below (an oversimplification of reality): 2-phases ======== (timer starts) -> Host sends SETUP token -> Host sends 8-byte control -> Peripheral sends ACK -> Host sends STATUS token -> Peripheral sends ACK (timer ends) 3-phases ======== (timer starts) -> Host sends SETUP -> Host sends 8-byte control -> Peripheral sends ACK -> Host or Peripheral sends DATA bytes -> Host or Peripheral sends ACK -> Host sends STATUS token -> Peripheral sends ACK (timer ends) As stated, this is an oversimplification of reality, but it's enough to illustrate how this works. -- balbi
Attachment:
signature.asc
Description: PGP signature
