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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
