On Wed, Apr 6, 2011 at 5:08 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> 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? Performance reasons mainly. If short_not_ok is set, we can program the dma for the full buffer length. Otherwise we program it for each packet. > > 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; Ok I am in for a short_not_expected flag. > UDC drivers would have to give the same result whether the flag was set or not. Agreed. I will see how I can fix my driver. > > Alan Stern > > Thanks, -- Mian Yousaf Kaukab -- 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
