Re: Understanding USB callback events and sequence

Hi,

On 3/22/22 22:43, Farhan Khan wrote:
> 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 response packet is handled after USB_ST_TRANSFERRED or 
USB_ST_CANCELLED / default, if something went wrong.

>>
>> 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?

Because it avoids races and additional state keeping in the driver. Many 
USB driver developers don't think about corner cases. For example what 
do you do if there is a USB transaction error. In other USB stacks like 
Linux and Windows, writing up the code to reset the USB endpoint is 
usually never done, because it requires a bunch of code and state 
keeping. In FreeBSD this piece comes for free and allows for continuous 
operation of your device, also if something should go wrong, which many 
developers simply don't think about. Just follow the existing examples 
in the FreeBSD kernel and you will be cool :-)

Consider the callback function a serialized event callback where you may 
re-fill and setup the next USB transfer.

> 
> 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`?

Is the RX xfer NULL?

If yes, there is something wrong in the usb_config.

If no, then maybe you didn't call usbd_transfer_start()

> 
> 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?

Because when you work with class devices, the endpoint number may change 
and you don't want each and every driver to go and parse the descriptors 
to figure this out.

--HPS