-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-
bounces@...] On Behalf Of Paul Sokolovsky
Sent: 30 January 2018 15:21
To: Sundar Subramaniyan <sundar.subramaniyan@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] USB: Question about usb_write() API

Hello Sundar,

On Tue, 30 Jan 2018 17:48:03 +0530
Sundar Subramaniyan <sundar.subramaniyan@...> wrote:

[]

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 understand that there are not going to be multiple USBD controllers
on a given chip and taking care of this in the driver won't cost much
from memory/CPU cycles point of view but from USB DC driver
implementation perspective this might save a lot of time if the stack
can abstract them.

Please let me know your opinions.

I'd suggest to look at this as a generic problem, not specific to USB
subsystem (e.g., there's the same issue in networking subsystem, etc.),
and consider the known best practices dealing with it. For example,
POSIX, when dealing with streams-of-bytes, always mandates possibility
of short reads/short writes (what you called "write in parts"). That
means that not drivers, but higher levels should take care of repeating
"long" operations.

This approach allows to implement simpler drivers (== easier to write,
less bugs), and allows for more flexibility on the higher levels.
But yes, the drawback of this approach is that it requires higher levels
to deal with repeating operations (POSIX passes that responsibility all
the way up to the application level, so each and every application needs
to have repetition loops*).

* Of course, that can be abstracted to a library. Different libraries
actually, because as mentioned, that's a flexible approach allowing to
implement different data flows and handling policies.

Although you raise a good point, I'm not convinced that this applies here. I think that what Sundar wants to know is whether this particular API call, usb_write(), was originally designed to be able to buffer data and fragment it into smaller USB-sized packets or instead it should mirror the state of whatever hardware FIFO it is using below, returning a number of bytes written different from the ones the caller asked to send. Beyond that there's the issue of the API call being blocking or not, which seems unclear given the different ways it is used in Zephyr.
To sum up, I thin he's trying to clarify the original intentions of the API designer in order to adapt the driver he's working on to it, not looking to modify the API itself.

Thanks,

Carles