Re: Understanding USB callback events and sequence

From: Farhan Khan <>
Date: Tue, 22 Mar 2022 21:43:44 UTC
On Tue, Mar 22, 2022, at 2:28 PM, Hans Petter Selasky wrote:
> This just means that the driver wants to check if it can send more 
> packets after the current job completed (USB_ST_TRANSFERRED).

So it "double-dips" in case there are any other packets while it has the CPU without having to call us usb_transfer_start() again. Cool!

> > Finally, I have been looking at USB traffic under wireshark (interpreted from usbdump -w file.pcap) and I see that every USB packet has a response from the device. Is this response packet handled by one of the RX callbacks? Or is this the same as TX's USB_ST_TRANSFERRED?
> The "DONE" callback is either USB_ST_TRANSFERRED or USB_ST_CANCELLED / 
> default.

Why is this necessary? Meaning, why not have the driver just process its "Done" step without the need for another callback?

Regarding Wireshark, are the reply USB packets from the device processed by a handler in any way? I ask because I am currently porting over some code and I do not seem to have my RX interrupt callback triggering and trying to determine why not. Perhaps something is wrong in my `usb_config`?

I wonder if it has anything to do with the endpoint address being a specific address rather than `UE_ADDR_ANY`? Curious why that value even exists rather than the exact address?

Questions glore! :)

Farhan Khan
PGP Fingerprint: 1312 89CE 663E 1EB2 179C 1C83 C41D 2281 F8DA C0DE