On Thu, 30 Jan 2014, Sarah Sharp wrote: > > That's a good plan. However _some_ restriction will turn out to be > > necessary. > > > > For example, what will you do if a driver submits an SG list containing > > 300 elements, each 3 bytes long? That's too many to fit in a single > > ring segment, but it's smaller than a TD fragment -- it's even smaller > > than maxpacket -- so there's no place to split it. (Not that I think > > drivers _will_ submit requests like this; this is just to demonstrate > > the point.) > > > > It ought to be acceptable to require, for example, that an SG URB > > contain no more than (say) 100 elements that are smaller than 512 > > bytes. > > At that point, the xHCI driver or USB core should probably use a bounce > buffer. It feels like we should attempt to push down scatter-gather > lists as far down in the stack as possible, so the upper layers don't > have to care what alignment, length, or random 64KB boundary splits we > need.
Okay. That should be doable, if awkward. > > ehci-hcd gets along okay with the restriction that each SG element > > except the last has to be a multiple of the maxpacket size. xhci-hcd > > can relax this quite a lot, but not all the way. > > What does the EHCI driver do when it receives a SG list from the USB > networking layer that violates this restriction? It never receives such lists. usb_submit_urb() returns -EINVAL before the request gets sent to ehci-hcd. Alan Stern -- 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
