On Wed, 3 Sep 2014, Andreas Larsson wrote: > Hi! > > In short: How should a udc driver handle a situation when the host sends > more data than req.length in the receiving OUT request? What > should be reported to the gadget driver? What should be done with the > excess data? It depends. If req.length is a multiple of the endpoint's maxpacket size then any excess must take the form of extra packets. The UDC should NAK these packets or apply them toward the next request on the endpoint's queue, if there is one. If req.length is not a multiple of the maxpacket size then an excess could take the form of a packet that's too long. The UDC should store as much of the data as possible (i.e., to up req.length) in the request's buffer and drop the rest, and the request should complete with a status code of -EOVERFLOW. > Currently the gr_udc driver does not accept OUT requests if req.length > is not a multiple of ep.maxpacket. This is because the hardware cannot > be told to write smaller data sizes than ep.maxpacket. (This works fine > for mass storage for instance that makes sure to supply request buffers > that are even multiples of ep.maxpacket, but not all gadget drivers do > this.) > > I am looking into lifting this limitation by using an internal buffer in > gr_udc.c in that is used instead of end of the req.buf that is > not (necessarily) a full multiple of ep.maxpacket and then copy received > data from the internal buffer to the request buffer. In other words, a bounce buffer. > The problem is that the gr_udc driver then can end up in the situation > where it receives more data than req.length (e.g. a full sized packet of > size ep.maxpacket). What should be done in the udc driver in this case? > What should be reported to the gadget driver? What should be done with > the excess data? See above. 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
