device_next, HID and transfer error handling in ->input_report_done()

[ndreys]

@tmon-nordic, @jfischer-no hoping to start a quick discussion with you guys about the subject. From my reading the code, in case when an EP is disabled we call udc_ep_dequeue() which will pop all of the outstanding net_bufs from the EP's FIFO and put them into a single net_buf with a bunch or fragments. So when that buffer is passed on to input_report_done() is the expectation that the user of the API know that they need to inspect frag field and potentially walk a linked list and to free all of the user-provided buffers?

Maybe it is too late to change that API in particular, but what do you think of an idea to instead:

1. Add config option to make pool_in be allocated with the space for data and have hid_dev_submit_report() do a memcpy() of a passed buffer (I have a patch for that, FWIW)
2. For zero-copy approach, create a low-er level version of hid_dev_submit_report() that would accept a user allocated struct net_buf, so that we can let the users avoid allocating a net_buf and a user-provided data buffer

Thoughts?

Thank you!

[tmon-nordic]

I would seriously prefer to not abuse net_buf frags for udc_ep_dequeue(). I think the best approach would be if each and every submitted net_buf would get its own corresponding completion callback.

I consider the USB stack merging requests into one to be a design flaw.

[ndreys]

OK, sure, but I guess the second part of my question was the more interesting one. Why do we even need to bother with splitting our IN transfer into those two pieces and then figure out a way hot to memory manager the user's part of it? Why not use net_buf and rely the codepaths freeing it that exist already?