Messages in this thread | | | Date | Wed, 30 Oct 2013 11:23:39 -0400 (EDT) | From | Alan Stern <> | Subject | RE: [RFC/PATCH v2 0/3] add gadget quirk to adapt f_fs for DWC3 |
| |
On Wed, 30 Oct 2013, David Laight wrote:
> > Wouldn't it be simpler and safer to just do this unconditionally? Sure, > > you need it for DWC3 because the controller refuses to do an OUT transfer > > at all if the transfer size is less than maxpacketsize. But it's possible > > that other controllers allow the transfer, and it works in most cases, > > but if an error occurs and the host sends too much data, they could > > overrun the buffer and crash your device. > > > > For example, the DWC2 databook says "For OUT transfers, the Transfer > > Size field in the endpoint's Transfer Size register must be a multiple > > of the maximum packet size of the endpoint". But I don't think the > > controller enforces that, it is up to the programmer to do the right > > thing. So that controller probably needs this quirk also. There could be > > more like that which we don't know about. > > > > So unless the buffer allocation code is in a real fast path, I would > > suggest to just do the aligned buffer allocation always. > > You wouldn't normally want to pad OUT transfers that way - if only > because of the additional USB bandwidth use.
What additional bandwidth use? Allocating more memory doesn't mean any additional data will be transmitted over the USB bus.
> Also, if the controller can't do (I assume bulk) OUT (and IN?) > transfers for less than maxpacketsize it seriously restricts > the type of devices that can be attached - none of the USB > ethernet devices would work.
The controllers _are_ capable of doing shorter transfers. You are missing the point: These are device controllers, not host controllers, so they don't have any choice about the length of an OUT transfer.
Alan Stern
| |