Hi,

Here's what bt_usb does:
https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/bluetooth/hci_usb/src/main.c#L665

When I looked at other drivers to see how they are implemented, the
designware USB driver seems to assume
the application/class drivers always support the "write in parts" method.
I'm not blaming the driver or it's
implementation but I just wanted to point out that there are drivers which
do not support handling chunked
write within them.

This sample was written for the DW driver, there was no other device driver
recently.

Another class driver, netusb does it a little differently by writing in
parts, but this too assumes the usb_write()
to be synchronous.

Here's what it does:
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/usb/class/netusb/netusb.c#L189

Please use subsys/usb/class for testing and as reference.

One more thing to consider is the write callbacks. In most cases, the
application/class driver is the one that registers
the Bulk/Interrupt endpoint callbacks and the device stack has no way of
knowing when to perform the next write, even
if it wants to handle this in the USB device stack.

The IN endpoint callback just informs that a endpoint buffer was transmitted to
the host.

My question now is, what is the ideal place to take care of truncation and
chunk handling as per the USB device stack design?
Why the driver needs to handle the multi-part write and synchronization?

I used the DW driver as a reference,
see https://github.com/zephyrproject-rtos/zephyr/pull/542
The Kinetis USB controller is a bit similar to NRF52, btw I would be glad
about review.

There is an effort to implement the transfer method. This is very convenient
from the function point of view, but may complicate the drivers.
Please review https://github.com/zephyrproject-rtos/zephyr/pull/5231

Regards,
Johann Fischer