On Wed, Jan 31, 2018 at 08:09:12AM +0530, Sundar Subramaniyan wrote:
Hi Paul, On Tue, Jan 30, 2018 at 9:55 PM, Paul Sokolovsky <[1]paul.sokolovsky@...> wrote:
A good clarification thus would be:
1. bytes_ret is always not-NULL. 2. There can always be short writes, number of bytes written is returned in *bytes_ret, caller must retry with remaining data as needed.
Note that this doesn't call for updates to existing drivers - they can keep accepting bytes_ret as NULL, and loop/block inside. But clients of this API definitely need to be updated, because otherwise they simply won't work with some drivers.
I think the same too. For now, new drivers should handle both the methods to be coherent with the API definition. If ret_bytes is NULL, then it shall to a blocked write taking care of fragmentation of the packet internally within the driver. Otherwise if it is != NULL, it can let the upper layer do the fragmentation and shall *not* block-wait for the completion of the current write on the USB bus, since we have write callback for notification purpose.
I think we do not have now this requirement not to block-wait. When working with sending fragmented packets you would prefer to block until all fragments are sent.
