David Laight wrote: > Some xhci (USB3) controllers have a constraint on the offset within a > bulk transfer of the end of the transfer ring. Mhm. > code using libusb can generate arbitrarily long transfers that usually > get split into 8k fragments. libusb splits transfers into 16k urbs, or doesn't with newer code when both kernel and libusb support scatter-gather. > In fact libusb always uses 8k fragments. Hm? Worst-case libusb-1.0 submits 16k urbs. libusb-0.1 I'm unsure about, but could check. When both sides support it, scatter-gather is used and a single urb is submitted. IIRC usbfs doesn't mess with urb buffers at all. Where's the 8k coming from? > This all means that the xhci driver needs to accept unlimited numbers > of 'aligned' fragments and only restrict the number of misaligned ones. libusb applications have so far never made efforts to align their buffers to anything. That seems to become relevant for zero-copy? //Peter -- 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
