quoted

If I'm understanding it correctly, you're always creating a bounce
buffer though it is not necessary (at least in my case - my test patch
proofed, that no changes at all are necessary). Why aren't you checking
for URB_NO_TRANSFER_DMA_MAP at the very beginning? Or is it your purpose
to first basically test your new code path? That would be ok.

Bounce buffer is only used when there is no other way of meeting the xHCI
alignment requirements. Worst case is once every 255 TRB, and for maximum 1024bytes.
Each TRB can point to 64K of data.

I can't go against the spec just because it doesn't cause issues in your
two usecases. The overhead of the bounce buffer usage is so small there's no
point in that kind of optimization.

URB_NO_TRANSFER_DMA_MAP only indicates the data was DMA mapped before driver 
submitted the URB, so usb core does not need to map it.

I was speculating that it could be a cause why data is so oddly aligned
(urbs with data starting at less than 512 bytes from 64k boundary), and
thus not meeting the xHC boundary and aligment requirements even if data
is otherwise contiguous.

xHC controller doesn't care who mapped the data, or if data is in a sg list
or already contiguous in urb->transfer_buffer as long as we follow
the aligment and boudary rules.

Bug was that driver assumed the data that needed to be bounce
buffered was in a sg list. Your cased proved it could be in
urb->tranfer_buffer instead.

quoted

I tested with the notebook (in both directions) - it seems to work - I
didn't get any problems though I used 24 kB bulk packets. Throughput was
unaltered high.

I'm doing the same test tomorrow with the other USB 3.1 controller!

Successfully tested on the other USB 3.1 host.

Thank you, much appreciated.

I think I'll submit this patch as it is (with a proper commit message)
can I add reported-by: Andreas Hartmann [off-list ref], and
tested-by: Andreas Hartmann <redacted> tags to the patch?

-Mathias