Re: [RESENDING RFC PATCH 4/4] usb: xhci: Use temporary buffer to consolidate SG

[Mathias Nyman <mathias.nyman@linux.intel.com>]

>>>> +static int xhci_map_temp_buffer(struct usb_hcd *hcd, struct urb *urb)
>>>> +{
>>>> +	void *temp;
>>>> +	int ret = 0;
>>>> +	unsigned int len;
>>>> +	unsigned int buf_len;
>>>> +	enum dma_data_direction dir;
>>>> +	struct xhci_hcd *xhci;
>>>> +
>>>> +	xhci = hcd_to_xhci(hcd);
>>>> +	dir = usb_urb_dir_in(urb) ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
>>>> +	buf_len = urb->transfer_buffer_length;
>>>> +
>>>> +	temp = kzalloc_node(buf_len, GFP_ATOMIC,
>>>> +			    dev_to_node(hcd->self.sysdev));
>>>> +	if (!temp) {
>>>> +		xhci_warn(xhci, "Failed to create temp buffer, HC may fail\n");
>>>
>>> Didn't kzalloc just warn before this?
>>>
>> Yes, It should.
> 
> Then do not spit out another message please.
> 
>>> And isn't this whole thing going to cause a lot more memory allocations
>>> per submission than before?
>>>
>> If buffer sizes for SG list are very small (less than MPS size per TRB_CACHE_SIZE)
>> yes, it will have more memory allocations. 
> 
> That's not good :(
> 

I actually recommended this after looking at the real numbers.

It was explained to me that the Synopsis xHC has a flaw that it will hang if its
TRB cache contains 16 chained TRBs (no ending TRB), and the combined TRB size
is _less_ than 1024 bytes.

So this only happens if a URB has a sg list with more than 16 entries whose
total size is less than 1024 bytes.

I was told this has not been seen ever in real life usage.

So in the unlikey case this is ever triggered we will end up allocating a small
bounce buffer, probably around 1024 bytes, and copy the data over from the sg-list.

(for HS speeds limits are 8 chained TRBs and 512 bytes)

- Mathias