On Thu, Jan 30, 2014 at 04:43:54PM -0500, Alan Stern wrote: > On Thu, 30 Jan 2014, Sarah Sharp wrote: > > > It should not matter what alignment or length of scatter-gather list the > > upper layers pass the xHCI driver, it should just work. I want to do > > this fix right, by changing the fundamental way we queue TRBs to the > > rings to fit the TD rules. We should break each TD into fragment-sized > > chunks, and add a link TRB in the middle of a segment where necessary. > > 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. > 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? Sarah Sharp -- 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
