On Wed, 6 Apr 2011, Mian Yousaf Kaukab wrote: > On Tue, Apr 5, 2011 at 4:18 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, 5 Apr 2011, Mian Yousaf Kaukab wrote: > > > >> Instead of removing short_not_ok can we use something like following? > >> bh->outreq->short_not_ok = (amount % maxp) ? 0 : 1; > >> short_not_ok is useful for example when it is not possible to do DMA > >> tranfers from usb controller's buffer to the memory for unaligned > >> lengths. > >> controller driver can decide to use dma or pio mode based on if short > >> packets are expected or not. > > > > You are trying to use the short_not_ok flag for something it wasn't > > designed for. Its real purpose is to allow drivers to delimit > > consecutive bulk transfers, in the case where the first transfer ends > > early. > > > > Besides, what is your controller going to do if a full-sized packet is > > expected but a short packet actually arrives? > > AFAIK, only mass storage class sets this flag in the kernel and in > mass-storage it is already a protocol error if a short-packet arrives > when a maxp size packet was expected. Actually the spec doesn't say how to handle such situations. The mass-storage gadgets don't treat it as a protocol error. > If we don't use short_not_ok, then we will have to wait for each > packet to arrive and then based on its size we can set dma. This is > what we do if short_not_ok is set to 0. What's wrong with doing this always? In general, it doesn't matter at all what the gadget driver _expects_. What matters is what actually _arrives_. The UDC has to transfer data correctly whether it comes from a short packet or not. Even when short_not_ok is set. > if short_not_ok=1, we assume that protocol is ensuring no short > packets so we optimize dma setup based on this. That is an incorrect assumption. Although, since no driver really uses short_not_ok, the point is moot. Indeed, it might be worthwhile to remove short_not_ok entirely from the gadget framework. We could replace it with a "short_not_expected" flag. But this would be meant only as a performance hint; UDC drivers would have to give the same result whether the flag was set or not. 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
