On Mon, 2017-06-05 at 09:02 +0300, Felipe Balbi wrote: > Hi, > > Benjamin Herrenschmidt <b...@kernel.crashing.org> writes: > > So another question :-) > > > > Is it legal to break down a bulk (or ISO) IN request into packets that > > are *smaller* than the Max EP size ? > > it depends if they are *supposed* to be two smaller packets or should be > two parts of a single one. > > > For example, I have a max EP size of 512 bytes and the gadget gives me > > an SG list where that's broken up into two segments (for example 2x256 > > bytes). > > > > Now, I'm still trying to confirm with the vendor what happens here, but > > I *suspect* that if I create 2 descriptors, the HW will break it down > > into 2 packets smaller than the max EP size on the wire. > > If that's the case, then your HW can't handle SG lists. I suspect there > will be some "chain" bit somewhere in the DMA descriptor which you can > use to tell DMA that these two segments are part of a single transfer.
No, there isn't, sadly. I've confirmed with the HW vendor. I might still enable SG with a fallback to bounce buffering to a pre-allocated packet buffer if I hit such a situation... It shouldn't be common for mass storage (though do we use sglists for the mass storage gadget ?), it might be more with networking if our network function does fragmented sends, I haven't checked. > > I do have vague memories of seeing "client" drivers in the past with > > make assumptions that some "replies" are fully contained in a single > > packet, so I'm tempted to say that this won't work, and thus should > > bounce such packets through a linear buffer but I'd like confirmation. > > yeah, USB makes that assumption. If host side requests 512 bytes and you > end up breaking that into two packets, host will receive only the first > 256 bytes, as short packets terminate transfers. Yup, that was indeed my assumption. Thanks for confirming. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
